В этом форму часто встречаются топики по поводу возможностей тех или иных серверов, сравнения этих возможностей, стонов "Хочу вот такую фичу" и злорадствований "У нас это есть, а у вас нету!".
А не поговорить ли нам и возможностях, которые наоборот - есть, но не нужны, мешают и т.п.?
Я работаю с 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... Полагаемся на сисадмина - софт настроен правильно... полагаемся на охрану - серверная закрыта, опечатана, доступ в неё строго ограничен... Как же без этого? Самому всё делать?

2All
Давайте всё-ж таки так: журналирование и безопасность - 2 раздельных вопроса. То, что они озвучены в одном сообщении - не 2 же было писать, верно?
2Павел & mir
Угу... двухфазная фиксация... безопасность..
угу... Берём базу статистики (по чему угодно) за прошлые периоды. Для надёжности ставим ей RO (данные то за прошлые периоды всё равно не меняются). Данные испортить не может никто. гарантировано. Значит, журналирование не нужно. Безопасность? Ну, да... читать, теоретически тоже не все могут... Бог с ним, пусть читают все. Зачем тогда нам безопасноть?
Начинаем считать по базе всякие полезные отчеты.
делаем нечто вроде

что происходит? при заполнении таблички #temp в лог пишется: что было и что стало. затем checkpoint переносит это из лога в саму базу. Т.е. Вместо одной операции записи данных я имею 3: Запись "Было" в лог, Запись "Стало" в лог, запись в базу.
Если при выполнении запроса произойдет ошибка - Вам очень будет нужно вернуть табличку #temp в прежнее состояние? Не думаю. Зачем в таком случае мне журналирование? Вроде бы как и ни зачем.
Однако, в случае ошибки пойдет откат, который, кстати, тоже занимает время (причем немало, не меньше, чем было время вставки, но, по моим наблюдениям от 1.5 до 3 раз больше).
Т.е., теоретически (на практике то как это сделаешь?) операции при отключенным журналировании должны быть минимум на 50% быстрее.
Следующее. Если мы всё пишем в лог, в 2-м размере, то и место под этот лог должно быть. Т.е. за ненужную мне возможность я плачу: процессорным временем, временем пользователя, дисковым пространством. Дорого получается.
Далее. В Informix, Oracle и (вроде бы) Sybase есть возможность тем или иным образом отключить журналирование для Таблицы/базы. Следовательно, необходимость в этом возникала и, по всеё видимости, неоднократно.

По поводу отключения безопасности. Произвести замеры возможности нет, т.к. нет возможности отключить систему безопасности. Но, как мне думается, если принять минимально возможные разрешения, то выигрышь от такого отключения действительно будет минималным.
2f_w_P
ну... если Васю охрана пропустит в опечатанную комнату... тогда у него будет доступ к подсети... Я ведь могу изобразить и картинку, где сервер приложений имеет 2 сетевые карты, одна уходит во внешний мир, другая - во внутреннее кольцо с сервером БД и между которыми нет роутинга. По идее.... должно работать.

2Tygra

после ошибки видим, что не вставился не только null, но и 1, т.е. операция вставки атомарна, при ошибке откатывается, т.е. ведеться журналирование. Это подтверржадется также тем, что table var представляются в иде временных табличек в tempdb. Кроме того, таблички у меня используются для передачи данных из процедуры в процедуру (правда, не временные, а постоянные разделенные по spid).
2Gluk
В MS SQL тоже. Для базы, на которой стоит RO. Но проблема в том, что читаю я из базы RO а пишу в tempdb, для которой журналирование ведеться.

2Tygra
Предметную область или всё-же инструмент? Инструмент - да, подтверждаю, знаю не досконально, не боюсь в этом признаться.
Если не сложно - дайте ссылку на ветку обсуждения table vars.
2SergSuper
Поставьте order by по вкусу - всё равно не вставляет, да и судя по описаниям не должна.
2Jimmy
Слышал, есть такая штука, кэширование... И что? То, что кто-то может эффективно выполнять ненужную мне работу - меня не радует ни капельки.

2All
Давайте определимся. Есть транзакции на уровне блока операторов. Есть транзакции (неявные) на уровне одного оператора (insert,update,delete)
Меня в некоторых случаях устраивает "транзакция" на уровне страницы, а не оператора. В чем неправильность моего желания?

2Mir
Первый и второй путь я никогда не отвергал и не отвергаю. Всемерно этим пользуюсь и т.д.
3-й путь - дорого, однако. По крайней мере заказчик считает, что дорого. В чем-то я с ним согласен.
4-й путь - не для меня. Можут быть, увы, может быть - к счастью.
Но! Где-то тут потерялся путь - правильная настройка сервера. И очень досадно, что нету в MS SQL такой настроечки, которая есть у других.
Хотя, если положить руку на сердце, мне вполне бы подошла опция типа

где n - количество строк, после которого надо делать commit
а то приходится делать вот так

2A. Chepack
Не, что касаемо модичикации данных и всё такое - там у меня претензий ни к скорости ни к журналированию ни практически ни к чему претензий нет. А вот к отчетности... Ну, есть. Ну, могу порешать (и решаю). Но хочется то большего и меньшими усилиями :-(