Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 О ненужных возможностях  [new]
locky
Member

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

Откуда: Томск
Сообщений: 1027
А сама СУБД не мешает? А то понатолкали, понимаешь, возможностей дурацких, да и место она на диске много занимает. Сотри-ка лучше эту гадскую СУБД и поставь-ка Quake или Tetris.
12 апр 04, 06:44    [623132]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Да, если Вам мешает то, ради чего (в частности) СУБД создавались (система безопасности), то, возможно, стоит подумать о смене средств разработки.
12 апр 04, 07:29    [623140]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
pkarklin
Member

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


dbf спасет отца русской демократии...
12 апр 04, 10:12    [623372]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
locky
Member

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

select ЛицевойСчет,Сальдо=СальдоВходящее+Начислено-Оплачено
from (select ЛицевойСчет,СальдоВходящее=Sum(Сальдо) from Остатки group by ЛицевойСчет) Остатки
left join
(select ЛицевойСчет,Начислено=Sum(Сумма) from Начисления group by ЛицевойСчет) Начисления on остатки.ЛицевойСчет=Начисления.ЛицевойСчет
left join
(select ЛицевойСчет,Оплачено=Sum(Сумма) from Оплата group by ЛицевойСчет) Оплата on остатки.лицевойсчет=Оплата.лицевойсчет

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

Oracle:

1. alter table nologging ...
3. To enable code to run with Invoker rights, an AUTHID clause needs to be used before the IS or AS keyword in the routine header. The AUTHID clause tells Oracle whether the routine is to be run with the invoker rights (CURRENT_USER), or with the Owner rights (DEFINER). If you do not specify this clause, Oracle by default assumes it to be AUTHID DEFINER.

а может все же "супер возможности" нужны ?

:)
13 апр 04, 13:26    [625721]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Green2
Member

Откуда: skype: green2x2
Сообщений: 13748
Система безопасности всегда мешает, но надо ей учится пользоваться.

И кроме того, в SQL Server есть такой пользователь как guest...

Заведи его, дай ему права админа и с безопасностью будет полный конец...
13 апр 04, 13:38    [625752]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
1. А в сторону OLAP смотреть не пробовали? А денормализовать (хотя бы остатки хранить) ? Если используете временные таблицы - попробуёте сделать их постоянными (тогда не будет логирования DML операций - их просто не будет).

2. Ну это просто смешно.. Поскольку сервер что-то там каждый раз проверяет - давайте вообще от безопасности откажемся.... А если в Вашу базу будет ходить не один клиент (аппликейшн-сервер), а несколько? В каждом систему безопасности городить? Так это дольше будет работать..

locky
3. права при выполнении - у меня широко используются выборки с переменными фильтрами. В местном FAQ рекомендуют реализовывать их с использованием DSQL

Необязательно. Набор фильтров хоть и велик, но конечен. Определите его и напишите выборку на каждый случай комбинации фильтров.
13 апр 04, 13:49    [625786]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
locky
Member

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

Откуда: glubinka
Сообщений: 4257
а может сервер по быстрее купить?

не один а 8 процов и памяти не 512 М а несколько Gb
и RAID10 вместо макстор в 5000 оборотов.
14 апр 04, 01:37    [627084]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
А вот не будет у меня в базу ходить никто, кроме сервера приложений!
А Вася Пупкин поставит себе EM и ага... Не по злобе, просто из любопытства.
14 апр 04, 07:58    [627174]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
Да, DDL-DML, конечно. Звиняйте, обдёрнулся.

Перечитал Ваш пост с условиями задачи. Типичный ETL в урезанном виде. Проблема безусловно непростая, но отменять журналирование даже для промежуточных операций - большой оптимизм с Вашей стороны. Какая будет польза от несогласованных результатов промежуточных вычислений? Что с ними делать? Только выкинуть и начать всё заново.

locky
2.А вот не будет у меня в базу ходить никто, кроме сервера приложений! Не надо говорить "А вдруг..." Если такое случится - ладно, включу. Но дайте возможность выключить!

Фигню говорите, дорогой товарищ. База данных является корпаративным ресурсом, обеспечивающим хранение, обработку и безопасность. Делать БД с прицелом только на одно приложение - глупо. Эти данные потом захотят использовать самыми неожиданными способами, если конечно догадаются....

locky
3. Исходные данные: 26 аттрибутов, поиск ведется по комбинациям из 12-ти параметров (справочник лицевых счетов). Сколько комбинаций насчитаем? Да, кстати... Еще предустановленные фильтры, как же без них... А всего справочников 65, в среднем по 5-6 параметров. Сколько мне процедур написать? Вариантов? А производительность их какова будет, а?

Нормальная будет производительность. Писал я отчёты для бухгалтерских систем, не напугаешь меня этим.

На Вашем месте я бы провёл инвентаризацию и анализ часто выполняемых запросов. И исходя из этого моделировал отчётные формы. С фиксированным набором полей ввода для фильтрации/группировки и форматом вывода. А для чересчур привередливых пользователей - универсальная отчётная форма. Если такую вообще можно себе вообразить...

Вам правильно советуют прикупить железо. То, что для достижения бОльшей производительности Вы хотите отказаться от самых существенных достоинств СУБД наводит на мысль, что либо Вы неправильно её используете, либо выжали всё, что возможно из имеющихся ресурсов. Второе вероятней.
14 апр 04, 09:20    [627264]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
locky
Member

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

declare @value
set @value = 'Value'
select * from SomeTable where Field = @value

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

select * from SomeTable where Field = 'Value'

А теперь тоже самое для связки 12 таблиц. Буду рад примерам.
Железо прикуплю, обязательно. Деньги в студию! Нету? Я так и думал. И у меня нету. И у заказчика нету.
Из ресурсов железа я еще не всё выжал, но надо же иметь какой-то запас.
P.S. Кстати, обратите внимание: в исходном сообщении об отказе от системы безопасности было написано "В теории". Т.е. ПОКА мне это не надо, но я могу представить себе ситуацию, когда мне такое понадобится.
14 апр 04, 11:25    [627677]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
В Oracle параметризованный запрос выполняется СУЩЕСТВЕННО быстрее своего аналога с литералами в том случае, если он ЧАСТО вызывается с РАЗНЫМИ параметрами. Если параметр ЧАСТО одинаков, лучше использовать литерал, так как это дает дополнительную информацию оптимизатору.
Издержками на передачу параметров можно пренебречь.
14 апр 04, 11:48    [627792]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Jimmy
Member

Откуда: г.Москва
Сообщений: 3136
права при выполнении - у меня широко используются выборки с переменными фильтрами. В местном FAQ рекомендуют реализовывать их с использованием DSQL. Это значит, что пользователь должен иметь права на select на все интересщющи таблицы/view. Не так уж и важно это... но всё-таки хотелось бы вот так: Exce(<sql>) as <user>

Для сервера приложений вполне нормально, что он _сам_ генерит SQL запросы, т.е использование ХП не нужно (это - один из вариантов DSQL, кстати). Таким образом, никаких контекстов T-SQL для EXEC не будет.

Насчет доступа к данным и распределения прав юзеров, так тут какое-то противоречие я вижу:
-- система безопасности не нужна
-- не хочу, чтобы пользователь имел права на select из всех таблиц.

Если исходить из того, что система безопасности все-таки нужна, то можно вполне грамотно ею воспользоваться, а именно:
-- Авторизацию пользователей проводить на уровне сервера приложений
-- Сам сервер приложений подключить к БД с единственной учетной записью, созданной специально для него
-- Для этой записи присвоить статус application role, что не позволит ее использовать вне сервера приложения


------------
Best regards, Jimmy
14 апр 04, 12:01    [627853]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Jimmy
Конечно, противоречие, если рассматривать эти 2 пожелания совместно. Я хочу чтобы можно было и отключить систему безопасности, и выполнять DSQL под указанными правами.
Подключение сервера приложений по Application Role решительно ничего не меняет - права всё равно будут проверятся и на это будет тратится драгоценное время.
2Gluk.
В MS SQL тоже, но только в том случае, если при разных значениях параметров генерируется один и тот же план запроса. Если же при разных значениях параметров могут быть сгенерированы разные оптимальные планы.... тут уж увы, велика вероятность, что предварительно скэшированный план не является оптимальным для данного случая.
14 апр 04, 12:37    [627986]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Gt.
Guest
кеширование спасает от hard parse, а не планов ...
14 апр 04, 13:00    [628059]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Поэтому при наличии параметров не строится никаких предположений о их значениях. hard parse нагружает Oracle настолько сильно, что в общем случае это выгоднее чем каждый раз составлять выгодный план для заданного значения параметров. Я уже сказал, что иногда выгоднее оставить литерал, но это скорее исключения чем правило.
14 апр 04, 13:09    [628093]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Jimmy
Member

Откуда: г.Москва
Сообщений: 3136
Подключение сервера приложений по Application Role решительно ничего не меняет - права всё равно будут проверятся и на это будет тратится драгоценное время.

???????

Пояснить можно? Время чего и на что?


------------
Best regards, Jimmy
14 апр 04, 13:30    [628182]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Павел Воронцов
Member

Откуда: Новосибирск
Сообщений: 2402
Блог
To Gluk (Kazan)
Насколько я знаю MS SQL там всё точно так же. Использование параметров - хорошая (и правильная) практика.
locky
Кто Вам сказал, что база данных - корпоративный ресурс??

Ну если это не так, то нафига такая БД вообще нужна? Если это не БД, а хранилище данных для конкретного приложения, и не более - храните всё в реестре. Тут кстати скорее всего и кроется источник всех Ваших проблем - Вы неверно трактуете БД, неправильно её используете. Я, конечно, извиняюсь, Вы имеете право обидеться и обозвать меня всякими словами, но, при всём моём уважении к Вам, это скорее всего так. Взгляд на БД как на корпаративный ресурс поможет не только лучше выстроить бизнес-процессы, но и (при необходимости) выбить деньги под новое железо. Траст ми.

locky
Кстати, отчетные формы не моделируются мной :-). Есть утвержденный перечень отчетных форм, четко описанных... Их и надо реализовывать.

Вот и замечательно! Вам же меньше работы (анализ требований уже выполнен хотя бы частично). Универсальная отчётная форма - безусловно абсурд, не стоит о ней.
14 апр 04, 13:41    [628241]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Мешает SQL - снесите нафиг.
автор
Подключение сервера приложений по Application Role решительно ничего не меняет - права всё равно будут проверятся и на это будет тратится драгоценное время.

С чего Вы взяли?
автор
А вот что Вася Пупкин сможет поставить и что не сможет поставит.... и будет ли у него доступ к подсети, в которой стоит SQL... это решает сисадмин, и я думаю, что он решит правильно.

Полагаться на других - глупо. Если сисадмин ошибется и кто-то сделает кирдык данным(например лицо, имеющее доступ в подсеть, не обязательно это ошибка сисадмина) и крайним будет DBA.
14 апр 04, 17:56    [629168]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
locky
Member

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

select * from SomeTable

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

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

2Гавриленко С.А.
Я говорил, что SQL мешает? Никогда такого не было, да и не скажу этого в будущем.
Полагаться на других... Дык ведь приходится... Полагаемся на производителя железа - RAID должен правильно считать контрольные суммы... На производителя софта - транзакции обладают свойствами ACID... Полагаемся на сисадмина - софт настроен правильно... полагаемся на охрану - серверная закрыта, опечатана, доступ в неё строго ограничен... Как же без этого? Самому всё делать?
14 апр 04, 20:49    [629460]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
Павел Воронцов
Member

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


Почему непремено вашим приложением? А другие приложения, которые хотят пользовать эту информацию - должны ходить через ваше приложение или накапливть ту же информацию?

Реестр - ненадёжно. Угу. Давайте теперь подумаем чем обеспечивается надёжность в СУБД? Правильно - именно тем, от чего Вы хотите отказаться. Двужфазная фиксация, журналирование и система безопасности. Вперёд - в реестр!

Вы не там ищете ресурсы для увеличения производительности. Подумайте об этом.
15 апр 04, 06:18    [629700]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Уважаемый Locky.
К сожалению, пока все ваши рассуждения на тему снижения производительности системы из-за (1) проверок безопасности и (2) журналирования не подкреплены цифрами. Все это напоминает разговор ни о чем. Разумеется, логика подсказывает, что эти факторы несколько замедляют работу (особенно журналирование). Однако насколько? Вы не думали, что возможно, сражаетесь с ветряными мельницами? Что эффект от полного устранения этих "мешающих" вам факторов будет хоть сколько-то заметен при вот таких-то и таких-то реальных условиях работы вашей системы. Опять-таки, гипотетической системы ("может помешать, если мне взбредёт в голову" и т.п.).
А народ тут тратит время, спорит...
Смотрится все это довольно забавно, но и печально, увы...
15 апр 04, 06:24    [629701]     Ответить | Цитировать Сообщить модератору
 Re: О ненужных возможностях  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
А вот что Вася Пупкин сможет поставить и что не сможет поставит.... и будет ли у него доступ к подсети, в которой стоит SQL... это решает сисадмин, и я думаю, что он решит правильно.
Т.е. предполагается, что сервер БД и сервер приложений в разных подсетях?
И что в подсети где стоит SQL сервер никаких пупкиных нет?
15 апр 04, 08:22    [629791]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить