Здравствуйте, Merle, Вы писали:

M>Ага, только надо не забыть делать это в многопользовательском режиме.
Точно!
M>Когда один пользователь сидит, то DBF может всех и сделает, а вот если их чуть больше, то любая реляционная база, изначально заточеная под многопользовательскую работу, обгонит всех со страшной силой.
Именно. Вообще я в свое время был потрясен, когда увидел шустродействие некоей проги, которая показывала карту землетрясений. Типа такой дипломный проект у одной моей знакомой. Нажимаем на кнопочку... Ап! И все уже там. Секунды три, не больше. И сколько, говорю, этих записей? А она скромно так: "триста тысяч..." Я на работу в шоке пришел. У нас тогда примерно 1000 записей в секунду на клиента приезжало. Потом подумал и понял, что там идет монопольное чтение плоского файла с предопределенной структурой. Все определяется, грубо говоря, скоростью вращения винта и шириной шины. А у нас — полноценный ACID.

Мораль: DBF в монопольном режиме на сканировании данных гарантированно порвет любой SQL сервер. Но как только появляются
— join
— ad-hoс queries, которым нужны не только индексы, но и статистика
— многопользовательская работа
практически любой SQL сервер порвет DBF на тряпки. Унизительные танцы с бубнами типа создания временных локальных копий таблиц и последующего их объединения с центральными, а также тщательной подгонки набора полей под каждую задачу я рассматривать не буду. Ибо это все — резьба по вазелину. Минимальное изменение в проект — и все поплыло.

Здравствуйте, Serginio1, Вы писали:

S> Только одним запросом ты данные не вытянешь.
S> Простой пример с вышеперечисленными результатами. Есть остатки есть движения товаров. Мне нужно посчитать количествой дней нахождение товара + количество проданного товара и периоды продаж (разница в днях между продажами). Затем усечь дни нахождения в продаже на недостоверно долгое время не продаж товаров. Все это для более достоверного прогноза времени и количества закупки и определения мертвых душ или не выставленного в продажу товара, что при большом ассортименте встречается очень часто.
Ничего не понял. Давай ты напишешь поподробнее, какие таблицы (что такое остатки, что такое движения, что такое "количество дней нахождение товара"). Что значит "усечь дни нахождения". В общем, опиши входные и выходные таблицы. А то может и вправду, SQL sux?

Здравствуйте, Serginio1, Вы писали:

S> ООП формализован очень хорошо.
Это неправда. То, что ты понимаешь под формализацией — не более, чем один из способов поддержки некоторых теоретических концепций. Например, Intel 80486 является некоторой реализацией машины Тьюринга. Или еще пример — страничное размещение данных и индексы — это один из способов реализации абстрактной реляционной алгебры. Реляционная алгебра ничего не говорит о формате представления. Она оперирует такими вещами, как
— множества значений (домены)
— N-ки (r1, r2, ..., rN), где каждый ri принадлежит некоторому домену Di
— отношения (реляции). Каждое отношение является подмножеством множества D1 x D2 x ... x DN, где буквой х обозначено Декартово произведение.
— операторы, определенные на отношениях. Фильтрация, объединение (union), пересечение и натуральное соединение являются примерами таких операторов.

Все. Далее доказываются некоторые теоремы о свойствах этих операций.
Удобно это тем, что свойства операций сохраняются независимо от реализации.

Ничего подобного для ООП не существует. Есть несколько попыток построить более-менее внятную математическую теорию, но все они плохо ложатся на современное программирование.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>Это неправда. То, что ты понимаешь под формализацией — не более, чем один из способов поддержки некоторых теоретических концепций. Например, Intel 80486 является некоторой реализацией машины Тьюринга. Или еще пример — страничное размещение данных и индексы — это один из способов реализации абстрактной реляционной алгебры. Реляционная алгебра ничего не говорит о формате представления. Она оперирует такими вещами, как
S>- множества значений (домены)
S>- N-ки (r1, r2, ..., rN), где каждый ri принадлежит некоторому домену Di
S>- отношения (реляции). Каждое отношение является подмножеством множества D1 x D2 x ... x DN, где буквой х обозначено Декартово произведение.
S>- операторы, определенные на отношениях. Фильтрация, объединение (union), пересечение и натуральное соединение являются примерами таких операторов.

S>Все. Далее доказываются некоторые теоремы о свойствах этих операций.
S>Удобно это тем, что свойства операций сохраняются независимо от реализации.

S>Ничего подобного для ООП не существует. Есть несколько попыток построить более-менее внятную математическую теорию, но все они плохо ложатся на современное программирование.

Объяснить ООП попытался в http://www.rsdn.ru/Forum/Message.aspx?mid=406541&only=1

Автор: Serginio1
Дата: 10.10.03

Но если эти принципы применять к БД то они прекрасно вписываются.
Если рассмотреть процессы происходящие на уровне команд процессора то разницы вообще никакой.
1. Память виртуальна и следовательно доступ к физической памяти происходит через посредника использующего индексную систему.
2. Прямых операций с памятью не существует. Сначала нужно загрузить данные из памяти в регистр (стек) процессора произвести определенные операции и затем снова выгрузить данные в память.
3. Для лучшего использования памяти применяются Менеджеры памяти, опять же построенные на индексировании неиспользуемой памяти, для более оптимального ее выделение. Так и хранение данных ввиде массивов с контролем удаленных записей для повторного использования тоже часто применяется в обычном программировании.
4.Использоване подсчета ссылок в интерфейсах определяет ссылочную целостность. При этом возможно хранение информации на ссылаемые объекты.
5. Отнщение построено на прямых (адресс в памяти) или коственных ссылках (индекс массива, значение ключа в Хэш таблице или SortedList)
Все то же, что и с БД
ООП позволяет абстрагироваться от всех низкоуровневых процессов, но эта поддержка встроена в компилятор.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Serginio1, Вы писали:

VD>>>Далеко не прекрасно. Иначе бы орлы из МС и напрягаться не стали бы. В сиквел-сервере кэширование свое, потому как прямой доступ к памяти значительно шустрее чем доступ к файловому кэшу.
S>> А файл мэппинг это не прямой доступ к памяти ????? Там если мне не изменяет память запись страницами. У меня к тебе небольшая просьба.Сравни мап файлами с SQL не сложно на просчете какой нибудь таблицы. А то что чтение из кэша медленней это понятно но достигает 150 мб за 0,375 сек у меня хоть и память 400 но шина 266.

AVK>Ты бы лучше, чем здесь трепаться, поинтересовался бы как работает тот же MSSQL с диском.
Буду очень признателен, за ссылочки. По моим знаниям организация работы с диском очень напоминает файл маппинг, то есть данные загружаются страницами и хранятся часто используемые страницы (а если хватает памяти то и все) а запись происходит сразу страницами с измененными данными.

Здравствуйте, Serginio1, Вы писали:

S> ООП позволяет абстрагироваться от всех низкоуровневых процессов, но эта поддержка встроена в компилятор.
Ты путаешь ООП с "объектно-ориентированным языком программирования". В формализме нет и не должно быть никакого компилятора. Это то же самое, как пытаться формализовать функциональное программирование при помощи терминов "возврат значения через стек" и "передача параметров в регистрах".
Чтобы немножечко посмотреть за пределы VMT и менеджеры памяти, рекомендую для себя ответить на следующие вопросы:
— поддерживается ли ООП в JScript?
— поддерживается ли ООП в Java?
— поддерживается ли ООП в Delphi?
-- а методы, помеченные как dynamic, это все еще ООП?
— поддерживается ли ООП в COM?

Каждая из этих технологий, если копнуть, достаточно существенно отличается от модели С++. У честного разработчика остается ровно два выхода: либо считать все, кроме С++, апокрифами, граничащими с ересью, либо признать, что
— ООП не тождественно эквивалентно "ссылке на структуру, которая хранит ссылку на VMT"
— ООП не тождественно даже триаде "инкапсуляция, наследование, полиморфизм"

Во втором случае оказывается, что пока что нет никакой мат.модели, которая бы описывала все имеющиеся интуитивные представления об ООП, не апеллируя к "дальний указатель" и "слот VMT". Вот об отсутствии этого формализма я и говорю.

Здравствуйте, mrhru, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> На самом деле просто интересно посмотреть на результты. При том что пул нитей ограничен. И на сколько синхронизация MultiReadWriteExcclusive еффективен. Спор пезсперспективен без достоверного сравнения.

M>MultiReadWriteExcclusive сам по себе очень эффективен. Особенно в реализации Борланда по сравнению с примером Рихтера — порядка 250 000 обращений к ресурсу против 100 000 (PIII 800, 5-10 читателей и 1 писатель).
M>Но ко внутренней работе БД MultiReadWriteExcclusive имеет очень небольшое отношение, потому что...

Говоря о MultiReadWriteExcclusive к БД подразумевалось различное использование БД, где основным действием является как раз чтение.
S>> Но почему то я уверен, что те затраты на блокировки, многоуровневые транзакции жрут ресурсов больше чем ламермские выкладки.

M>... для реальной работы всё же нужны и блокировки, и многоуровневые транзакции и различные уровни их изоляций и т.д.

Нужно делать сравнения и для каждого случая предусматривать самые эффективные методы.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Merle, Вы писали:

M>>Ага, только надо не забыть делать это в многопользовательском режиме.
S>Точно!
M>>Когда один пользователь сидит, то DBF может всех и сделает, а вот если их чуть больше, то любая реляционная база, изначально заточеная под многопользовательскую работу, обгонит всех со страшной силой.
S>Именно. Вообще я в свое время был потрясен, когда увидел шустродействие некоей проги, которая показывала карту землетрясений. Типа такой дипломный проект у одной моей знакомой. Нажимаем на кнопочку... Ап! И все уже там. Секунды три, не больше. И сколько, говорю, этих записей? А она скромно так: "триста тысяч..." Я на работу в шоке пришел. У нас тогда примерно 1000 записей в секунду на клиента приезжало. Потом подумал и понял, что там идет монопольное чтение плоского файла с предопределенной структурой. Все определяется, грубо говоря, скоростью вращения винта и шириной шины. А у нас — полноценный ACID.

S>Мораль: DBF в монопольном режиме на сканировании данных гарантированно порвет любой SQL сервер. Но как только появляются
S>- join
S>- ad-hoс queries, которым нужны не только индексы, но и статистика
S>- многопользовательская работа
S>практически любой SQL сервер порвет DBF на тряпки. Унизительные танцы с бубнами типа создания временных локальных копий таблиц и последующего их объединения с центральными, а также тщательной подгонки набора полей под каждую задачу я рассматривать не буду. Ибо это все — резьба по вазелину. Минимальное изменение в проект — и все поплыло.

Я не буду больше повторять про TSE+ДБФ.
Но на базе ДБФ легко строится Клиент — Сервер например через DCOM. Любого вида отчет даже с иерархическими группировками с построением в памяти. Пример группирока из более миллиона записей с группировкой по двум полям до более 300 0000 записей с последующей статистческой обработко1 до 10 000 записей за 6-10 сек в зависимости от кэширования. При этом числовые данные хранятся в строковом виде (BCD).
Использую Клиент — Сервер например через DCOM для прямого доступа к таблицам 1С с интеграцией полученных отчетов в 1С. То есть люди работают в 1С через посредника по сетке 10 мб и сервер РIII 400 Абсолютно не подозревая что работают через посредника. БД под гигабайт. Все летает.
Построив объектную модель http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019
Хочу то же сделать и для SQL но объектного программирования на сервере пока нет жду юкон. Но когда он выйдет все идеи ООП к БД как на стороне Сервера так и клиента легко реализуются. Нужно только подобие конфигуратора 1С но с автоматической генерацией объектов с применением Net и реструктуризации БД.
Причем некоторые выгружают из SQL в дбф для формирования сложных отчетов.

Здравствуйте, Serginio1, Вы писали:

S> Но на базе ДБФ легко строится Клиент — Сервер например через DCOM. Любого вида отчет даже с иерархическими группировками с построением в памяти. Пример группирока из более миллиона записей с группировкой по двум полям до более 300 0000 записей с последующей статистческой обработко1 до 10 000 записей за 6-10 сек в зависимости от кэширования.
Сколько клиентов?
Иначе, это все не более чем занятная математика.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Но на базе ДБФ легко строится Клиент — Сервер например через DCOM. Любого вида отчет даже с иерархическими группировками с построением в памяти. Пример группирока из более миллиона записей с группировкой по двум полям до более 300 0000 записей с последующей статистческой обработко1 до 10 000 записей за 6-10 сек в зависимости от кэширования.
M>Сколько клиентов?
M>Иначе, это все не более чем занятная математика.
У меня их немного до 10, причем так как изначально по сети с этими же файлами работают через 1С и дополнения произведенные по сети не попадают в Кэш приходится при каждом запросе открывать и закрывать таблицы и все запросы выполнять поочереди, но скорость такова, что для обычных отчетов задержка вообще не заметна. Просто не хотелось для каждого клиента запускать свой удаленный сервер (Automation Object).
Применяется разумеется только грязное чтение. Но в этом отчете есть небольшая хитрость для второй группировки применяюется однонаправленный список учитывающий индекс выборки по дате, те последнее значение равно или меньше текущего. Но б деревья тоже очень быстрые.
Да и речь я сейчас веду не о ДБФ а о построении объектной модели над РБД и о полном вычислении на сервере с применением ООП.

Здравствуйте, Sinclair, Вы писали:

S>Во втором случае оказывается, что пока что нет никакой мат.модели, которая бы описывала все имеющиеся интуитивные представления об ООП, не апеллируя к "дальний указатель" и "слот VMT". Вот об отсутствии этого формализма я и говорю.
Согласен, что нет стандарта и четкого описания модели ООП и каждый как хочет так и ... на
понятии "инкапсуляция, наследование, полиморфизм". Но в Delphi а затем и в Net реализация понятия ООП всетаки четко очерчена (за исключением Интерфейсов) и эти принципы можно применять и к БД.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Только одним запросом ты данные не вытянешь.
S>> Простой пример с вышеперечисленными результатами. Есть остатки есть движения товаров. Мне нужно посчитать количествой дней нахождение товара + количество проданного товара и периоды продаж (разница в днях между продажами). Затем усечь дни нахождения в продаже на недостоверно долгое время не продаж товаров. Все это для более достоверного прогноза времени и количества закупки и определения мертвых душ или не выставленного в продажу товара, что при большом ассортименте встречается очень часто.
S>Ничего не понял. Давай ты напишешь поподробнее, какие таблицы (что такое остатки, что такое движения, что такое "количество дней нахождение товара"). Что значит "усечь дни нахождения". В общем, опиши входные и выходные таблицы. А то может и вправду, SQL sux?
Есть
1. Таблица остатков товаров на каждый период (обычно месяц).
2. Таблица движений товаров где присутствуют как реквизит тип движение (продажа, возврат итд) и одним из параметров документ сделавщий движение.
IDDOC, ПриходРасход, Количестводвижения, итд
3. Таблица документов в которых содержится значение 1 или 0 сделано ли движение.

Задача посчитать количество дней нахождение товара на складе, количество проданного товара с учетом возврата, посчитать интевалы дней без продаж, для усечения недостоверно долго не продаваемых товаров.
В итоге должны получит группировку товар,день,ПриходРасход, продажаВозврат с последующим вычислением остатков на каждый период, для дальнейшего подсчета дней в продаже и получение интервалов не продаж.

Здравствуйте, Merle, Вы писали:


M>Вот кстати неплохой критерий для Serginio. Если на обычной десктопной машине его система с LockFile/Ex будет в OLTP задачах при многопользовательской нагрузке выдавать хотя бы около тысячи транзакций в минуту, то будем считать его затею успешной..
Я не веду речь обфайл сервере. Только о Клиент сервер. А блокировки через механизм синхронизации аналогично нетовским SyncBlokIndex и таблицы SyncBlok со сылками на структуры типа критических секций или реализации через хэш таблицы с теми же SyncBlok

Здравствуйте, Serginio1, Вы писали:

S> Я не веду речь обфайл сервере. Только о Клиент сервер.
Как раз РСУБД — это "клиент-сервер", а ты из файл-серверной архитектуры пытаешься выстругать клиент-сервер с помощю DCOM'а.

Здравствуйте, Serginio1, Вы писали:

S> Согласен, что нет стандарта и четкого описания модели ООП и каждый как хочет так и ... на
S>понятии "инкапсуляция, наследование, полиморфизм". Но в Delphi а затем и в Net реализация понятия ООП всетаки четко очерчена (за исключением Интерфейсов) и эти принципы можно применять и к БД.

Дело в том, что прямого применения этих принципов к БД (которые, кстати вполне четко очерчивают и интерфейсы) совершенно недостаточно для построения полноценной модели. Сразу теряется как минимум возможность делать предикатный поиск, который собственно и делает RDBMS такими могучими. Вот и получается, что либо дудочка (инкапсуляция, наследование, полиморфизм), либо кувшинчик (ad-hoc queries). Ограничение поисковых возможностей ODBMS исключительно навигацией существенно сужает круг возможных решений и понижает производительность.
Текущий ответ индустрии на эти философские вопросы — это трехзвенка. Частным случаем ее является ORM (Object — Relational Mapping). К сожалению, такое решение разделяет приложение на несколько искусственнные уровни, причем граница между ними достаточно условна.
Если в случае замкнутой системы (будь то С++ или SQL) мы получаем адекватное описание решения в терминах самой системы, и окружающая среда (RDBMS или компилятор) заботятся о мелких деталях типа проверки на целостность и оптимизацией конкретной реализации, то в случае разделенной системы нет никакого способа автоматически разделить логику на два уровня с сохранением всех преимуществ обоих подходов. Существуют вполне хорошие паттерны для случаев реализации поведения системы в рамках сервера приложений (объекты-глаголы), а состояния системы в рамках RDBMS (объекты-сущности). Но это очень узкое подмножество задач. Пока что оказывается проще поместить объекты-глаголы внутрь RDBMS, чем, собственно, и занимаются сейчас Oracle и MS.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Я не веду речь обфайл сервере. Только о Клиент сервер.
M>Как раз РСУБД — это "клиент-сервер", а ты из файл-серверной архитектуры пытаешься выстругать клиент-сервер с помощю DCOM'а.
Я только выправляю ситуацию приводя ее к нормальному виду. Мне очень хочется перенести объектную модель созданную для ДБФ на SQL, но без Юкон все придется таскать на клиента, да и трех звенка тоже не поможет. С другой стороны в основе SQL однопользовательская база, а организация доступа через серверную программу.
У меня просто нет другого выхода. Но с другой стороны работает и показывает прекрасные результаты с таким ужасным гибридом Файл — сервера с Клиент-Сервером работающими вместе. А объектное программирование позволяет делать достаточно легко отчеты любой сложности.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Sinclair, Вы писали:

S>>Ничего не понял. Давай ты напишешь поподробнее, какие таблицы (что такое остатки, что такое движения, что такое "количество дней нахождение товара"). Что значит "усечь дни нахождения". В общем, опиши входные и выходные таблицы. А то может и вправду, SQL sux?
S>Есть
S>1. Таблица остатков товаров на каждый период (обычно месяц).
т.е. это (КодТовара(PK), Дата(pk), количество)? Назовем ее Ostatok.
S>2. Таблица движений товаров где присутствуют как реквизит тип движение (продажа, возврат итд) и одним из параметров документ сделавщий движение.
S>IDDOC, ПриходРасход, Количестводвижения, итд
S>3. Таблица документов в которых содержится значение 1 или 0 сделано ли движение.

S> Задача посчитать количество дней нахождение товара на складе
Что это такое? Вот у нас остаток на начало периода — 40 яблок. Вот у нас на 3 день продали 5 яблок, На 5 день еще 10, а на 6й день 2 яблока вернули. Сколько вернет функция "количество дней нахождение товара на складе"?
S>, количество проданного товара с учетом возврата,
Это вроде табличка (КодТовара, количество)? Примерно так:

select КодТовара, Sum(количество) from 
(select Ostatok.КодТовара as КодТовара, Ostatok.количество as количество) from Ostatok where Дата = @BaseDate 
  union all 
 select Move.КодТовара as КодТовара, (case ПриходРасход when "приход" then 1 when "расход" then -1)*Move.Количестводвижения as Количество from Move where Дата>@BaseDate)
 group by КодТовара

Вполне себе летать будет.
S>посчитать интевалы дней без продаж, для усечения недостоверно долго не продаваемых товаров.
Что такое "посчитать интервалы дней без продаж"? Сколько дней в отчетном периоде продаж не было по каждому товару? Ну, ребята... селектим DateDiff(day, @intervalstart, @intervalend)-count(distinct datepart(day, Дата)) и получаем ответ.

S> В итоге должны получит группировку товар,день,ПриходРасход, продажаВозврат
ну это тупой group by из движения.
S>с последующим вычислением остатков на каждый период,
это тоже тупой group by оттуда же.
S>для дальнейшего подсчета дней в продаже и получение интервалов не продаж.
Я что-то не понимаю, как остатки влияют на дни продаж/дни непродаж... Если мне более внятно объяснят структуру табличек и потребного отчета, я в два счета наваяю SQL версию этого дела. В один стейтмент. И она не будет требовать предварительного "престраивания индексов" для получения требуемых результатов.

В общем, что я могу сказать? Тот, кто покажет мне DBF с чем угодно поверх него в списках TPC-C, убедит меня в том, что SQL сливает в учетных системах.

Здравствуйте, Serginio1, Вы писали:

S> Я только выправляю ситуацию приводя ее к нормальному виду.
Вот это спорно..

S>Мне очень хочется перенести объектную модель созданную для ДБФ на SQL, но без Юкон все придется таскать на клиента, да и трех звенка тоже не поможет.
Не надо ничего таскать на клиента сверх необходимого. Но то что необходимо должно выполняться только на клиенте или в среднем звене. Не надо пытаться нагрузить сервер не свойственной ему работой.
Юкон здесь мало что изменит, разьве что будет чуть удобнее, поскольку среднее звено будет физически писаться в рамках сервера БД, а не в отдельном слое.

S> У меня просто нет другого выхода.
Очень сильно сомневаюсь...
Я бы понял, если бы решалась какая-нибудь очень нестандартная задача, но насколько я успел разобраться, здесь обычный склад/бухучет.
А это, на данном этапе развития мировой IT индустрии, являются хлебом, маслом, сыром и икрой РСУБД. Наработана куча кода, известны удачные и неудачные примеры, на все возможные грабли наступлено и они тщательно помечены флажками нужного цвета. Так что...

S> Но с другой стороны работает и показывает прекрасные результаты с таким ужасным гибридом Файл — сервера с Клиент-Сервером работающими вместе. А объектное программирование позволяет делать достаточно легко отчеты любой сложности.
Эти результаты показываются в отдельной, практически тестовой задаче с небольшой нагрузкой. Малейшее изменеие, и с очень большой вероятностью придется переписывать все приложение, слой за слоем, от самого верхнего, до самого нижнего уровня. Отсутствие же формальной теории хранилища объектных данных, о которой здесь уже много было говорено, не позволит выработать в достаточной степени универсальный слой отвечающий непосредственно за доступ к данным и написать хоть какое-то подобие оптимизатора.

Здравствуйте, Sinclair, Вы писали:


S>> Задача посчитать количество дней нахождение товара на складе
S>Что это такое? Вот у нас остаток на начало периода — 40 яблок. Вот у нас на 3 день продали 5 яблок, На 5 день еще 10, а на 6й день 2 яблока вернули. Сколько вернет функция "количество дней нахождение товара на складе"?
S>>, количество проданного товара с учетом возврата,
S>Это вроде табличка (КодТовара, количество)? Примерно так:
S>

S>select КодТовара, Sum(количество) from 
S>(select Ostatok.КодТовара as КодТовара, Ostatok.количество as количество) from Ostatok where Дата = @BaseDate 
S>  union all 
S> select Move.КодТовара as КодТовара, (case ПриходРасход when "приход" then 1 when "расход" then -1)*Move.Количестводвижения as Количество from Move where Дата>@BaseDate)
 без проблем
S> group by КодТовара
S>

S>Вполне себе летать будет.
S>>посчитать интевалы дней без продаж, для усечения недостоверно долго не продаваемых товаров.
S>Что такое "посчитать интервалы дней без продаж"? Сколько дней в отчетном периоде продаж не было по каждому товару? Ну, ребята... селектим DateDiff(day, @intervalstart, @intervalend)-count(distinct datepart(day, Дата)) и получаем ответ.

S>> В итоге должны получит группировку товар,день,ПриходРасход, продажаВозврат
S>ну это тупой group by из движения.
S>>с последующим вычислением остатков на каждый период,
S>это тоже тупой group by оттуда же.
S>>для дальнейшего подсчета дней в продаже и получение интервалов не продаж.
S>Я что-то не понимаю, как остатки влияют на дни продаж/дни непродаж... Если мне более внятно объяснят структуру табличек и потребного отчета, я в два счета наваяю SQL версию этого дела. В один стейтмент. И она не будет требовать предварительного "престраивания индексов" для получения требуемых результатов.

В итоге должны получится две таблицы
Товар,Остаток
и
Товар,день,ПриходРасход,ПроданоВозвращено
Group By Товар,день
И из этих данных получить требуемую задачу. Если бы не было задачи с подсчетом интервалов не продаж задача легко решается через хранение таблицы (массива)
Товар,остаток, датаПоявленияТовараВПродаже, КоличесвоПродаж, ПоследнийДеньПродажи проиндексировнному по Товар (или хэшированному) и получения дней в продаже
ДатаКонцаТовара-датаПервогоПоступления.
Где ДатаКонцаТовара дата обнуления остатков или конец периода.
Где датаПервогоПоступления дата когда товар появился в продаже, или дата расчета начальных остатков если товар был в продаже. При обнулении остатка товара обнуляем датаПервогоПоступления а при появлением проставляем дату движения. То же и с продажами. Алгоритм достаточно простой.
S>В общем, что я могу сказать? Тот, кто покажет мне DBF с чем угодно поверх него в списках TPC-C, убедит меня в том, что SQL сливает в учетных системах.
Да не сливает он. Просто много задач где простое применение SQL не годится. Ситуация с построением объектов на таблицах позволяет очень гибко и оптимально строить любые расчеты с минимумом затрат по времени как по разработке так и вычислениям. Я за гибрид SQL с ООП на стороне сервера. А данные показанные на ДБФ говорят о больших скоростях (в архитектуре Клиент-Сервер). И этот гибрид легко можно создать на Юкон.

Вышеописанная задача должна встречаться очень часто и интересно посмотреть на результаты. А основным лимитирующим процессом являются парсинг чисел из строк (Фокспрошный дубовый формат).

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Согласен, что нет стандарта и четкого описания модели ООП и каждый как хочет так и ... на
S>>понятии "инкапсуляция, наследование, полиморфизм". Но в Delphi а затем и в Net реализация понятия ООП всетаки четко очерчена (за исключением Интерфейсов) и эти принципы можно применять и к БД.

S>Дело в том, что прямого применения этих принципов к БД (которые, кстати вполне четко очерчивают и интерфейсы) совершенно недостаточно для построения полноценной модели. Сразу теряется как минимум возможность делать предикатный поиск, который собственно и делает RDBMS такими могучими. Вот и получается, что либо дудочка (инкапсуляция, наследование, полиморфизм), либо кувшинчик (ad-hoc queries). Ограничение поисковых возможностей ODBMS исключительно навигацией существенно сужает круг возможных решений и понижает производительность.

S>Текущий ответ индустрии на эти философские вопросы — это трехзвенка. Частным случаем ее является ORM (Object — Relational Mapping). К сожалению, такое решение разделяет приложение на несколько искусственнные уровни, причем граница между ними достаточно условна.

Я уже говорю об РБД с ООП надстройкой на стороне сервера и организации конфигурирования данной системы.
В которую прекрасно вписывается организация таблиц 1С. То есть наследование структур таблиц, и единый спосб навигации, создание програмной связи и генерация объектов.
Я уже говорил Merle, что только исходники объектов 1С достигает 1MB. Но программирование с автозавершением кода и типизацией доставляет не только удовольствие и скорость разработки, но и защиту от ошибок.
При изменении БД все объекты автоматически заного генерируются.
И уход от трехзвенки реален с появлением Юкон.