В этом форму часто встречаются топики по поводу возможностей тех или иных серверов, сравнения этих возможностей, стонов "Хочу вот такую фичу" и злорадствований "У нас это есть, а у вас нету!".
А не поговорить ли нам и возможностях, которые наоборот - есть, но не нужны, мешают и т.п.?
Я работаю с MS SQL Server 2000.
Мне мешают:
1. Журналирование DML (частично мешают).
2. Система безопасности (в теории может помешать, если мне взбредёт в голову перейти на 3-х звенку)
3. Она же - при выполнении exec (<sql>)

2All
нет, СУБД мне не мешает, и dbf мен не спасёт.
Давайте по пунктам.
1. Журналирование.
Стоит простая задача: посчитать сальдо по лицевым счетам.
Входные данные: Сальдо входящее, начисления, оплаты.
Можно написать запрос вида

Мощность "Остатки" ~ 500000, "начисления" ~4500000 (за месяц), Оплата ~450000 (за месяц). Считать поэтому приходиться небольщими порциями, используя временные таблицы. поскольку вставка и удаление из временных таблиц логгируется - это происходит несколько медленнее, чем было бы без логгирования.
Более того, существуют гораздо сложные расчеты, при вычислении которых нельзя обойтись простой выборкой, а необходимо использовать промежуточные результаты. Согласен, вполне возможно, что без журналирования можно было бы получить выигрышь "всего" 10-15%... но это тоже немало
2. Система безопасности.
Предположим, у меня 3-х звенка: Сервер БД, сервер приложений, клиент.
К серверу БД гарантировано ходит только Сервер приложений. Безопасность опять-таки обеспечивается средним слоем. Однако, при каждом обращении среднего слоя к СУБД происходит проверка прав и т.п., что, ессно, снижает общую производительность. Согласен, ненамного (возможно ненамного, без системы безопасности никто ведь не пробовал).
3. права при выполнении - у меня широко используются выборки с переменными фильтрами. В местном FAQ рекомендуют реализовывать их с использованием DSQL. Это значит, что пользователь должен иметь права на select на все интересщющи таблицы/view. Не так уж и важно это... но всё-таки хотелось бы вот так: Exce(<sql>) as <user>

2Павел
1. В сторону OLAP? Смотрел. Только сводные данные по мощности равны 80% исходных.
Остатки храним, а как-же.
DML - data manipulation l (не путать с DDL - data definition), т.е. insert, update, delete....
у меня не используются temporary tables, только постоянные (правда, размещенные в tempdb) - процедуры имеют свойство обмениваться данными, так что...
2.А вот не будет у меня в базу ходить никто, кроме сервера приложений! Не надо говорить "А вдруг..." Если такое случится - ладно, включу. Но дайте возможность выключить!
3. Исходные данные: 26 аттрибутов, поиск ведется по комбинациям из 12-ти параметров (справочник лицевых счетов). Сколько комбинаций насчитаем? Да, кстати... Еще предустановленные фильтры, как же без них... А всего справочников 65, в среднем по 5-6 параметров. Сколько мне процедур написать? Вариантов? А производительность их какова будет, а?

2Lepsik
Сервер - 2 камня, 2Gb памяти (max для MS SQL Server 2000 SE). Можно купить новый - но это дороже, причем, если мне не изменяет память, значительно.
2f_w_p
А вот что Вася Пупкин сможет поставить и что не сможет поставит.... и будет ли у него доступ к подсети, в которой стоит SQL... это решает сисадмин, и я думаю, что он решит правильно.
2Павел.
А с чего вы взяли, что результат будет несогласован? Исходя из соображений, что при расчете отчета обязательно произойдет ошибка? Ну, пока такого не было. А если такое случится... ну что, начнут заново.
Кто Вам сказал, что база данных - корпоративный ресурс?? Что на этом сервере кроме одного приложения еще что-то будет крутится? В том случае, что я описывал - имеется ОДНО приложение, сильно нагружающее сервер БД. Ставить на этот же сервер что-либо еще - просто глупо. Тем более, что в данном случае сервер БД используется как надежное хранилище данных для конкретного приложения, и не более.
Кстати, отчетные формы не моделируются мной :-). Есть утвержденный перечень отчетных форм, четко описанных... Их и надо реализовывать.
А универсальная отчетная форма... ну, на досуге попробуйте придумать универсальную форму, позволяющую построить отчет по льготникам, начислениям, перерасчетам, оплатам, субсидиям, возмещениям, пеням (по всем возможным разрезам аналитики)...
И, кстати, я нигде не писал, что в отчетах надо делать поиск и т.д. там не надо. Искать надо в справочниках. Вот там это должно быть быстро.
По поводу DSQL - попробуйте мне доказать, что

выполняется быстрее, чем

А теперь тоже самое для связки 12 таблиц. Буду рад примерам.
Железо прикуплю, обязательно. Деньги в студию! Нету? Я так и думал. И у меня нету. И у заказчика нету.
Из ресурсов железа я еще не всё выжал, но надо же иметь какой-то запас.
P.S. Кстати, обратите внимание: в исходном сообщении об отказе от системы безопасности было написано "В теории". Т.е. ПОКА мне это не надо, но я могу представить себе ситуацию, когда мне такое понадобится.

2Jimmy
Конечно, противоречие, если рассматривать эти 2 пожелания совместно. Я хочу чтобы можно было и отключить систему безопасности, и выполнять DSQL под указанными правами.
Подключение сервера приложений по Application Role решительно ничего не меняет - права всё равно будут проверятся и на это будет тратится драгоценное время.
2Gluk.
В MS SQL тоже, но только в том случае, если при разных значениях параметров генерируется один и тот же план запроса. Если же при разных значениях параметров могут быть сгенерированы разные оптимальные планы.... тут уж увы, велика вероятность, что предварительно скэшированный план не является оптимальным для данного случая.

2Jimmy & Гавриленко С.А.
Время чего и на что будет тратиться?
Давайте попробуем поглядеть

Упрощенно:
1. Проверяем, что у пользователя или его группы есть доступ к табличке SomeTable на select
2. Проверяем, что у пользователя или его группы нет запрета на select из SomeTable
3. Аналогично для каждой из столбцов таблицы SomeTable
4. Если все права есть - выбираем.
Если мне память не изменяет (а может, если не прав - поправьте) разрешения храняться в sysprotects. Индексы есть? Нету? Будем сканить.
Есть на что время потратить? С моей точки зрения, есть. Согласен, данная проверка происходит достаточно быстро. При единичном запросе. Усложним. Запросов стало N. Нет, N мало, пусть M. Умножаем время проверки X на количество запросов M - получаем Z секунд времени, потраченного на НЕНУЖНУЮ мне функциональность.

2Павел.
Сама по себе БД - не ресурс, ресурс - это информация, предоставляемая моим приложением. Да, можно хранить всё в реестре :-) но, во первых, мало места в йём, во вторых медленно, в третьих - ненадежно... и т.д.
Да, БД - хранилище, но всё-ж таки достаточно интеллектуальное.

2Гавриленко С.А.
Я говорил, что SQL мешает? Никогда такого не было, да и не скажу этого в будущем.
Полагаться на других... Дык ведь приходится... Полагаемся на производителя железа - RAID должен правильно считать контрольные суммы... На производителя софта - транзакции обладают свойствами ACID... Полагаемся на сисадмина - софт настроен правильно... полагаемся на охрану - серверная закрыта, опечатана, доступ в неё строго ограничен... Как же без этого? Самому всё делать?