Андрей ЛеонидовичУважаемый Alex.Czech !

И это мы уже обсудили. Просто напоминаю:

- количество экземпляров объектов;
- количество экземпляров других объектов, связанных с конкретным экземпляром объекта по конкретной связи;
- количество экземпляров для каждого значения в индексах

поддерживаются автоматически при вводе/удалении/обновлении экземпляров.

По неиндексированным характеристикам ТАКИХ данных нет.

Прошу прощения, я не все тут читал... а в MS SQL такие данные по неиндексированным характеристикам есть. Точнее, могут быть, если завести статистику. И это часто делается, причем именно для тех данных, для которых индекс заводить смысла нет - скажем, чтобы SQL Server, как и я, человек, всегда знал, что процент выполненных проводок в таблице оных проводок на реальной работающей системе обычно равен 90-100% и таким образом условие
WHERE Accepted=1
ни в коем случае не следует воспринимать как такое, с которого надо победоносно начинать выполнять запрос

А что, пардон, Информикс под Виндами (речь именно о Виндах идет как я понимаю) на каждую клиентскую коннекцию создает новый процесс ? А у него ничего не трескается когда коннекций становится скажем 500 ?

Тогда я не понимаю такого повышенного внимания к фразе "Начиная с версии 5 для каждой клиентской коннекции вместо процесса стал создаваться thread". Переделка правильная, и фраза правильная :)

Андрей ЛеонидовичУважаемый Alex.Czech !

Я считаю, что даже для "Р"СУБД эта идея - архитектурное излишество.
А для ОСУБД, в которой принципиально нет понятия "настройка приложения", и в которой индексы являются полноценной частью данных (в отличие от "реляционных" систем) - это абсолютно не нужно.

Если уж Вы привели этот пример с проводками...
В Вашей таблице могло бы быть поле, в котором хранится значение как раз для не выполненных проводок, с типом индекса "пустые не хранить". Это проще, надежнее и не менее "экономично", чем поддержка статистики без индекса. Ведь Вам, насколько я понял, нужно быстро получать не выполненные проводки, чтобы их выполнить ? Извиняюсь, конечно, что "полез" в приложение, не зная его.
Да и MS SQL я перестал тщательно изучать после 6.5, когда стало ясно, что с "реляционностью" уже больше ничего не изменится. Может там до сих пор нет типа индекса "пустые не хранить" ? В Oracle, по крайней мере до 9-ки, не было даже банального индексирования пустых значений...

Нет, вы не совсем правильно поняли... мне надо получить отчет типа оборотной ведомости за неделю. И естественно в этом отчете должны фигурировать только "выполненные" проводки, невыполненные в него не включаются. Разумный человек, считая это самостоятельно по бухгалтерской книге, сначала отберет проводки за неделю, а потом уже начнет суммировать, по ходу дела отбрасывая "неисполненные" проводки, если будет знать, что их там одна на 1000. И SQL Server сделает ровно то же самое. Если будет знать что проводок 1 на 1000. А откуда ему это узнать ? Из статистики, разумеется.

Так что в системах, где оптимизатора запросов нету в виде отсутствия запросов, и роль оптимизатора выполняет специальный программист, пишущий программы обхода деревьев, статистики не нужны, конечно. Вместо статистики там тот самый специальный программист, знающий что "неисполненных" проводок всего 1 на 1000 и проверять это условие надо в последнюю очередь. Но лично мне больше нравится идея со статистикой, чем с увеличением фонда оплаты труда

Ну в принципе создавать процесс вместо thread-а - это даже несомненно круче :) Только очень накладно для Виндов

Тем более что речь идет о клиентских коннекциях... Оракл вообще вон можно так настроить что у него все коннекции будут через 1 thread настроить, было бы желание Это ж не говорит о том, что он не мулти-thread-овый

По поводу индексов "NULL не хранить" - сдается мне, вы прекрасно знаете, что таких индексов нету в MS SQL :)

Индекс по дате разумеется есть, иначе говорить не о чем. Поле "Невыполненные" вместо "Выполненные" не поможет, потому что тогда условие примет вид
WHERE NotAccepted=0, и это условие все равно будет выполняться для 90-99% проводок и применять его надо в последнюю очередь

И еще - мне с вами трудно что-то обсуждать в смысле сравнения "Р"СУБД и ООСУБД, потому что вы про "Р" что-то знаете (хотя и далеко не все, но многое), а я про ОО ничего. Только не предлагайте приходить на семинар, я зубы-то полечить не могу найти времени сходить :)

Андрей ЛеонидовичЯ же честно сказал, что после 6.5 ПРЕКРАСНО уже не знаю.
WHERE NotAccepted=1 (а не 0).


НЕТ. Это "невыполненные" проводки, а мне надо для оборотной ведомости выполненные. Или вы предлагает мне сначала посчитать по всем, потом по невыполненным, а потом вычесть из первого второе ? Это дольше будет, даже если на бумажке вручную считать, а в СУБД-то тем более :)

vybegalloЯ что-то перестал понимать вашу логику изложения. При чем тут крутизна ?
И, кстати, вы хотите сказать, что Оракл - multithread-ный ? Т.е. одному соединению соответствует одна или более нить, а не один или более процесс ?

Под Виндами - несомненно. Под Виндами одному instance-у Ораклу несомненно и безусловно соответствует один процесс oracle.exe. Не верите - посмотрите в task manager-е

Андрей ЛеонидовичТак Вы хотите сказать, что оптимизатор при условиях на индексированное поле "Дату" и неиндексированное и без статистики поле "Выполненные проводки" будет сначала использовать "Выпоненные проводки" ?

А Вам не кажется, что реализация Вашей логичной фразы "по ходу дела, отбрасывая лишние проводки", была бы не лишней в любой СУБД ?

Не будет, а "может быть будет". Причем, что характерно, может быть он будет и прав - если запрос будет не за неделю, а за 10 лет, и процент "выполненных" проводок не 90, а 5

Андрей ЛеонидовичОткуда же он знает, что 5 БЕЗ СТАТИСТИКИ ?

Так е-мое - с того ж разговор и начался, что не знает ! Зато по индексу знает, какой процент проводок попадет в диапазон. И он может ПРЕДПОЛОЖИТЬ, что выгоднее начать с условия Accepted=1, тем более что там равенство, а тут диапазон.

Вот чтобы он не предполагал, а знал, и нужна статистика по полю Accepted. А индекс, очевидно, не нужен, только место занимать