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

Откуда:
Сообщений: 122
добрый день.
до недавнего времени работал в фирме, основной продукт которой базируется на MS SQL Server 2008R2: сотни таблиц, десятки тысяч строк t-sql кода в процедурах, бизнес логика на сервере. несколько баз данных.
разработчикам запрещено использовать многие возможности: триггеры, виды, дефолтные значения, constraints, вычисляемые поля, синонимы, брокеры, loopback linked server, внешние ключи, relationships, поле с автоинкрементом, ещё несколько, сейчас не припоминается.
запрет исходил от главного DBA, создателя системы. основная идея: базу данных в которой нет перечисленных объектов, легче поддерживать и развивать.
кое-что из запрещенного в принципе легко заменяется, например вместо видов почти везде можно использовать функции; но есть вещи, без которых очень тяжело работать.
я пытался найти какую-нибудь информацию о таком виде разработки. нашлось много примеров, когда разработчики на C# или C++ отказываются от применения каких-либо методик или возможностей языка, довольно разумные аргументы. но о БД мне не удалось найти ничего похожего.
вопрос, несколько расплывчатый: кто-нибудь встречался с подобными вещами? существуют ли аргументы в пользу таких ограничений в БД? был бы очень рад ссылкам на материалы по этому поводу. спасибо.
4 апр 13, 20:12    [14137682]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
miksoft
Member

Откуда:
Сообщений: 38850
За отказ от constraints и внешних ключей я бы уволил такого DBA.
Триггеры и VIEW тоже весьма полезны, ибо альтернативой нередко являются значительно более масштабные изменения в софте. А иногда и вовсе альтернативы нет, если софт не самописный.

Без остального, наверное, можно обойтись без особого ущерба.

У нас таких ограничений нет, но перед созданием чего-то серьезного принято уведомлять DBA, чтобы он оценил последствия со своей точки зрения, и сдать ему код для создания этого чего-то, чтобы он у него был.
4 апр 13, 20:26    [14137728]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
SERG1257
Member

Откуда:
Сообщений: 2874
Полагаю речь идет о старом добром холиваре: где хранить логику внутри БД или вне ее.
>существуют ли аргументы в пользу таких ограничений в БД?
Все аргументы в пользу вытаскивания логики из БД.
Удешевление разработки (не нужно держать разработчиков на TSQL)
Удешевление лицензий (лишний проц на сервере БД стоит дороже чем вне ее)
Легче перенести приложение под другую БД
и прочая прочая
В то же время не надо сбрасывать со счетов обычную дурость - головокружение от успехов.
4 апр 13, 21:14    [14137868]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Arhat109
Member

Откуда: из СССР
Сообщений: 3430
valv,

Базу данных, которая не содержит данных - ещё легче поддерживать... собственно и поддерживать то не надо, если и приложений нет... да и сама такая база - нафиг? Можно и не держать. Просто платить зарплату ДБА и пусть даже на работу не ходит. Делов-то. Зато точно ничего не упрут и не заломают. Никто между прочим!

... эт-та, хде такое... (хочу туда на место ДБА, платформа значения не имеет)
4 апр 13, 21:49    [14137932]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
valv
вопрос, несколько расплывчатый: кто-нибудь встречался с подобными вещами? существуют ли аргументы в пользу таких ограничений в БД?
Встречался, аргументы существуют.

Но в вашей ситуации какой то перебор.
Почему лучше хардкодить в запросах имена баз и серверов вместо использования синонимов, непонятно? Конечно, если базы строго одного наименования, то без синонимов попроще, нагляднее, но всё таки это ограничение развития, может сказаться в будущем.
Функции вместо вьюх вообще плохо, лучше уж копипастить код.
Дефолтные значения, constraints, внешние ключи тоже обязательно нужны, они тоже упрощают поддержку и развитие.

В общем, странно.
SERG1257
Полагаю речь идет о старом добром холиваре: где хранить логику внутри БД или вне ее.
В данном случае не об этом, ТС пишет: "бизнес логика на сервере"
SERG1257
Все аргументы в пользу вытаскивания логики из БД.
В данном случае эти аргументы их ДБА считает как раз против вытаскивания логики из БД.

Модератор: Тема перенесена из форума "Проектирование БД".


Сообщение было отредактировано: 4 апр 13, 23:19
4 апр 13, 22:54    [14138054]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
У нас примерно так:

триггеры - нет (и, надеюсь, не будет), хотя output юзаем
виды - есть конечно
дефолтные значения - избегаем
constraints - вроде нет кроме оговоренных в этом списке отдельно
вычисляемые поля - не было, но скоро будут
синонимы - есть
брокеры - нет
loopback linked server - нет за ненадобностью
внешние ключи, relationships - нет (вернее, есть, но not enforced)
поле с автоинкрементом - куда же без них?
4 апр 13, 23:31    [14138136]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Оппть
Guest
valv
разработчикам запрещено использовать многие возможности: триггеры, виды, дефолтные значения, constraints, вычисляемые поля, синонимы, брокеры, loopback linked server, внешние ключи, relationships, поле с автоинкрементом, ещё несколько, сейчас не припоминается.


Какой-то 1с прям получается
4 апр 13, 23:43    [14138171]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Оппть
Guest
valv
добрый день.
разработчикам запрещено использовать многие возможности: триггеры, виды, дефолтные значения, constraints, вычисляемые поля, синонимы, брокеры, loopback linked server, внешние ключи, relationships, поле с автоинкрементом, ещё несколько, сейчас не припоминается.


Если вообще все типы constraints нельзя, то в таблицах primary key нету? это не база, а помойка получается..
4 апр 13, 23:47    [14138182]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
Оппть
Если вообще все типы constraints нельзя, то в таблицах primary key нету? это не база, а помойка получается..
Уникальный индекс вполне себе заменяет ПК.

Сообщение было отредактировано: 5 апр 13, 00:10
5 апр 13, 00:10    [14138247]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
valv
Member

Откуда:
Сообщений: 122
Гавриленко Сергей Алексеевич
У нас примерно так:
триггеры - нет (и, надеюсь, не будет)

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

какие универсальные недостатки триггеров вы видите,
если просто их наличие идёт вразрез с вашей надеждой?

вам не кажется несколько предвзятым сам подход - просто взять и неиспользовать триггеры совсем, вместо того чтобы ограничить ситуации, в которых разрешено их применять?
5 апр 13, 01:21    [14138327]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
valv
Гавриленко Сергей Алексеевич
У нас примерно так:
триггеры - нет (и, надеюсь, не будет)

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

какие универсальные недостатки триггеров вы видите,
если просто их наличие идёт вразрез с вашей надеждой?

вам не кажется несколько предвзятым сам подход - просто взять и неиспользовать триггеры совсем, вместо того чтобы ограничить ситуации, в которых разрешено их применять?
Есть один мощный аргумент против триггеров - отсутствие хотя бы одной объективной причины их использовать. Короче, нафиг не нужны.

З.Ы. Речь про обычные триггеры. Есть один DDL-триггер для логирования изменений кода.

Сообщение было отредактировано: 5 апр 13, 01:28
5 апр 13, 01:24    [14138330]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
З.Ы.Ы. А субъективно не нравятся, потому что логику размазывают.
5 апр 13, 01:27    [14138333]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
valv
какие универсальные недостатки триггеров вы видите,

Триггер может рекурсивно выполниться многократно...
Существует ограничение в 32 уровня вложенности...
5 апр 13, 01:32    [14138334]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
Гавриленко Сергей Алексеевич
З.Ы.Ы. А субъективно не нравятся, потому что логику размазывают.
Для борьбы с этим недостатком следует просто аккуратнее следить за размещением логики в триггерах.
5 апр 13, 01:35    [14138336]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
sphinx_mv
Гавриленко Сергей Алексеевич
З.Ы.Ы. А субъективно не нравятся, потому что логику размазывают.
Для борьбы с этим недостатком следует просто аккуратнее следить за размещением логики в триггерах.
Мне и так есть за чем последить, вы не поверите.
5 апр 13, 01:42    [14138343]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
valv
Member

Откуда:
Сообщений: 122
Гавриленко Сергей Алексеевич
Есть один мощный аргумент против триггеров - отсутствие хотя бы одной объективной причины их использовать. Короче, нафиг не нужны.
З.Ы. Речь про обычные триггеры. Есть один DDL-триггер для логирования изменений кода.

а логгирование изменений данных в таблице? надёжное, я имею в виду, независимое от внешних сущностей.
5 апр 13, 01:43    [14138344]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
valv
Гавриленко Сергей Алексеевич
Есть один мощный аргумент против триггеров - отсутствие хотя бы одной объективной причины их использовать. Короче, нафиг не нужны.
З.Ы. Речь про обычные триггеры. Есть один DDL-триггер для логирования изменений кода.

а логгирование изменений данных в таблице? надёжное, я имею в виду, независимое от внешних сущностей.
А у нас нет "внешних" сущностей. Поэтому спокойно логируется все через output.
5 апр 13, 01:49    [14138349]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
valv
Member

Откуда:
Сообщений: 122
Гавриленко Сергей Алексеевич
А у нас нет "внешних" сущностей. Поэтому спокойно логируется все через output.

если таблица изменяется из нескольких процедур, вам надо дублировать код логирования.
а если изменение сделано, скажем, разработчиком из management studio, то оно не логируется.

впрочем, если разработчики никогда не ошибаются, а изменения в таблице делаются строго из одной процедуры, проблемы снова нет, не так ли?
5 апр 13, 01:55    [14138350]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
valv
Гавриленко Сергей Алексеевич
А у нас нет "внешних" сущностей. Поэтому спокойно логируется все через output.

если таблица изменяется из нескольких процедур, вам надо дублировать код логирования.
У нас, за редким исключением, более чем в одной процедуре не меняется
valv
а если изменение сделано, скажем, разработчиком из management studio, то оно не логируется.
Скажем, менять что-то в обход стандартных процедур -- это тоже скорее исключение.
valv
впрочем, если разработчики никогда не ошибаются, а изменения в таблице делаются строго из одной процедуры, проблемы снова нет, не так ли?
Ошибаются, и очень много. Именно поэтому у нас есть толковые тестеры, которые эти ошибки ловко вылавливают.

Но вы не напрягайтесь. У нас довольно специфичный самописный проект, который позволяет в очень приличном количестве моментов высказывать обоснованную точку зрения, которая расходится с привычным общественным мнением. Ну или троллить, как кто-то скажет.
5 апр 13, 02:06    [14138353]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
valv
какие универсальные недостатки триггеров вы видите,
Недостаток - размазывание логики.

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

Дефолтные значения - стараюсь избегать, но используется выборочно, например, при добавлении полей в работающую систему, для более плавного и прозрачного добавления поля, и если при этом нельзя это поле делать NULL
5 апр 13, 09:05    [14138588]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
alexeyvg
Но я не такой принципиальный противник триггеров, как Гавриленко Сергей Алексеевич :-)
Я не принципиальный противник. Как только они понадобятся, так сразу и будут.
5 апр 13, 12:25    [14139597]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Guf
Member

Откуда: Новосибирск
Сообщений: 659
valv,

мои 5 копеек
Пользователи указали на ошибку, мой коллега взялся её решать, и говорит мне: "Смотри, выполняю ХП из ситемы, данные в таблицу добавляются, а из QA нет!"
Я говорю, что не может такого быть, давай, говорю, скрипт. (Я как раз в то время тестировал перезд с 2000 на 2005 и у меня была SSMS 2005).
Смотри, говорю, выполняется! Данные в таблицу добавились!
Полтергест?! Нет! Тригер INSTEAD OF
Если приложение = 'QA', то ниче не делать, иначе делать, то что просили
5 апр 13, 12:49    [14139816]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Гость333
Member

Откуда:
Сообщений: 3683
Guf
Полтергест?! Нет! Тригер INSTEAD OF
Если приложение = 'QA', то ниче не делать, иначе делать, то что просили

Хочу уточнить — это вы привели как аргумент в пользу отказа от триггеров?
5 апр 13, 12:53    [14139859]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Guf
Member

Откуда: Новосибирск
Сообщений: 659
Гость333,

Да, конечно!
Система покупная, мы были свято уверены, что в ситеме нет тригеров, о чем бло русским по белому написано в документации.

Мы поискали ещё по sysobjects нашли ещё 2, которые реализовывали логику FOREIGN KEY между тремя таблицами. Но там таких вывертов не было, решили не трогать пока. Вдруг апдейты от разработчиков, то да сё...
5 апр 13, 13:00    [14139904]     Ответить | Цитировать Сообщить модератору
 Re: ограничения на использование возможностей БД  [new]
Guf
Member

Откуда: Новосибирск
Сообщений: 659
Гость333
Хочу уточнить — это вы привели как аргумент в пользу отказа от триггеров?

Простите, не правильно прочитал ваш вопрос...
Я не ратую за отказ от тригеров совсем. Все возможности, которые предоставляет СУБД можно и иногда нужно использовать, НО с умом.
Если бы я писал тот тригер, я бы его написал иначе, типа: если действия выполняются из родной системы, то делать то что нужно, иначе ничего не делать.
5 апр 13, 13:04    [14139936]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить