Ограничения в реляционных базах данных - почему бы не удалить их полностью?

20

Есть ли какая-либо причина для создания ограничений между таблицами (внутри SQLserver) в настоящее время? Если да, то когда? Большинство приложений в моей области построены на объектных принципах, а таблицы объединяются по требованию. Спрос основывается на потребности из приложения. Я не буду загружать связку ограниченных таблиц для простого поиска, который, в свою очередь (после действия), потребует еще одного простого поиска.

Инструменты ORM, такие как EntityContext, Linq2Data, NHibernate, также сами обрабатывают ограничения, по крайней мере, вы знаете, какие таблицы нужны друг другу. Делать ограничения внутри сервера - это просто делать (заставлять) одни и те же изменения дважды?

Обычно это не вопрос для принятия решения, но эта база данных разработана совершенно по-другому. Дизайн выглядит хорошо, в основном отражает объекты, используемые приложениями. Меня беспокоит то, что все ограничения, сконфигурированные внутри SQLserver с «не каскадом». Это означает, что вы должны играть «искать и находить» при кодировании новых запросов к базе данных. В некоторых случаях требуется до 10 уровней точного порядка, чтобы сделать одно удаление.

Это удивляет меня, и я не уверен, как справиться с этим.

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

Как бы вы действовали в этом сценарии?
Почему бы просто не удалить все ограничения из БД и сохранить их на уровне приложения?

независимый
источник
6
Вы планировали всегда получать доступ к данным с помощью одного инструмента ORM? Или вы планировали «весело» реплицировать все ограничения правильно для каждого используемого инструмента ORM?
Donal Fellows
1
На мой последний комментарий к Питеру я должен согласиться. Смысл полагаться на все ограничения на кодовую базу (и удалять их из базы данных) был очень узким и, вероятно, полностью применим к недолговечным приложениям. Возможно также для некоторых разработчиков / проектов RAD.
Независимо
4
Незначительная мелочь: я думаю, что это немного сбивает с толку, когда вы называете связи между внешними ключами между таблицами «отношениями». «Отношения» в реляционной базе данных - это сами таблицы, а не соединения. Особенно, когда мы тогда поговорим о «реляционном дизайне» - это означает таблицы или внешние ключи?
Томас Падрон-Маккарти
Благодарность. Я называю «связи между таблицами» для ограничений. Следовательно, вы, вероятно, правы, что я вижу «реляционную базу данных» для принципов построения таблиц (структура таблиц). Еще более точное описание было бы «шаблоном проектирования» применительно к базе данных «отношение к объекту».
Независимо
1
Ваша база данных переживет код вашего приложения. Кроме того, ваш ORM снижает производительность вашего приложения, и есть большая вероятность, что вы захотите обойти его, по крайней мере, в определенных случаях использования. Если вы не знаете это сейчас, вы узнаете это в конце концов. samsaffron.com/archive/2011/03/30/… . Кроме того, удаление всех ограничений делает вашу базу данных совершенно неспособной защитить ее собственную целостность, когда ею злоупотребляют приложения, отличные от вашего, которые могут быть чем угодно, от другого реального приложения до исполнителя в холле с Excel.
Крейг

Ответы:

46

Две основные причины не удалять ограничения из БД :

  • Доступ к нему может получить больше приложений, сейчас или в будущем , которые могут использовать или не использовать ORM. Даже если разработчики этих приложений добросовестно дублируют все существующие ограничения (что может быть значительно сложнее при использовании низкоуровневых решений не-ORM), это всегда дополнительная работа. А если нет, даже одного небольшого упущения достаточно, чтобы нарушить целостность схемы ... это то, что вы не хотите рисковать. В большинстве компаний данные, хранящиеся в их БД, являются основой их бизнеса, поэтому их целостность должна обеспечиваться любыми средствами. И проверенное и проверенное лучшее средство для достижения этой цели - реализовать как можно больше ограничений в БД.
  • Оптимизатор запросов во многом опирается на ограничения, известные на уровне БД. Если вы удалите ограничения, производительность запросов может начать ухудшаться . Вы можете не сразу заметить это, но однажды оно ударит вас, и к тому времени может быть уже слишком поздно, чтобы это легко исправить. Суть дела в том, что производительность БД имеет тенденцию снижаться при пиковой нагрузке, когда существует наименьшая возможность для тщательного, продуманного улучшения конструкции, подкрепленного точными измерениями производительности и подробным анализом для точного определения основных причин.

Ваш конкретный случай звучит так, как будто схема БД изначально была сгенерирована инструментом ORM (или разработана кем-то, не имеющим большого опыта работы с реляционным миром), поэтому она неоптимальна с точки зрения отношений. Вероятно, лучше проанализировать и улучшить его в сторону более «естественного» реляционного дизайна, сохраняя его в соответствии с представлениями ORM. В этом анализе может быть полезно привлечь эксперта по БД.

Петер Тёрёк
источник
5
@Jonas, тогда поговори с парнем о предполагаемых проблемах с его дизайном БД. Относительный и объектно-ориентированный - это два разных мира, и ни одно из них не является «улучшением» по сравнению с другим, и оба имеют свое место. Разработка приложения на C # на реляционных принципах является такой же большой ошибкой, как и разработка БД с помощью ОО.
Петер Тёрёк
3
@Jonas, размышляя над вашими обновлениями: если вам нужно писать слишком сложные запросы для достижения, казалось бы, простых вещей со схемой БД, это либо признак того, что дизайн БД не соответствует своей цели, либо что вы недостаточно квалифицированы (пожалуйста, не обижайтесь, из вашего поста не очевидно, насколько вы опытны с SQL. Как заявление об отказе от ответственности, я сам далек от того, чтобы быть экспертом.)
Péter Török
1
У меня, вероятно, есть некоторые выражения, чтобы научиться воспринимать себя :). Я перечитал вопрос и ответы, и мне пришлось вернуться. Безусловно, есть сильная сторона - иметь БД в качестве мастера для всех ограничений. Все системы должны быть разработаны из этого. Очень узкий взгляд, чтобы сказать, что кодовая база сделает эту работу. Если у каждой системы может быть свое собственное решение об ограничениях, то это закончится высоким хаппаралом с неверно предложенными отношениями и целыми таблицами, осиротевшими. Если не сейчас, то это происходит позже с другими кодерами.
Независимо
8
«Это может быть доступно большему количеству приложений, сейчас или в будущем». Не говоря уже о каком-то администраторе базы данных, выполняющем необработанные SQL-запросы для решения проблемы с базой данных, пока пользователи ждут ...
Томас Падрон-МакКарти
5
+1: если БД хранит бизнес-данные (не только конфигурацию приложения и т. Д.),
То
27

Приложения могут приходить и уходить, но данные живут вечно. В моей компании БД старше 30-40 лет, она будет жить до тех пор, пока компания существует. Приложения меняются, разработчики приходят и уходят. Лучше иметь целостность и хорошую логическую модель данных. Таким образом, кто-то может смотреть на данные и получать осмысленное понимание без необходимости проходить сложную кодовую базу. Это также помогает в отчетности значительно. Кроме того, приложения могут и будут иметь ошибки, и ограничение БД является защитой от этого. Моя позиция по умолчанию - иметь как можно больше ограничений (FK и check).
Единственная причина, по которой не будет ограничений, заключается в том, что ваш шаблон проектирования не допускает этого, например, проблемы с таблицей в иерархии или проблемами с производительностью.

softveda
источник
Я скажу, что вы делаете очень мудрый совет здесь. Мое мнение может лучше соответствовать разработке RAD или любой другой разработке, где приложения имеют короткий срок службы - просто ради минимизированного обслуживания при разработке.
Независимо
15

Меня беспокоит то, что все ограничения, сконфигурированные внутри SQLserver с «не каскадом».

Это не беспокоит меня, это означает, что кто-то проявил здравый смысл. Каскадные удаления часто очень вредны для базы данных. Во-первых, иногда вы хотите, чтобы удаление не удалось, если у вас есть данные в связанных таблицах. Например, если у вас есть клиент, у которого есть заказ в прошлом, вы не хотите, чтобы он был удален, или вы теряете данные о том, для кого был заказ, и каскадное удаление избавит вас от записи, которая испортит вам финансовую отчетность. ,

Вы, кажется, думаете, что легкость разработки - это самая важная вещь. В мире баз данных это просто неправда. Целостность данных - это самая важная вещь, за которой следуют производительность и безопасность данных. Если для написания запросов требуется больше времени, пусть будет так.

База данных обычно используется многими приложениями = одним или несколькими веб-сайтами или настольными приложениями, приложением для создания отчетов, веб-службами, окном запросов, процессами ETL и т. Д. Если вы не применяете ограничения на уровне базы данных, вы сначала теряете целостность данных, поскольку одно из этих приложений может не соответствовать всем правилам. Во-вторых, вы должны кодировать эти противоречия несколько раз и переписывать их, если позже решите использовать другое приложение. В-третьих, вы не можете заранее контролировать, будет ли необходимость выполнять какую-то задачу обслуживания данных, которая не будет выполняться через приложение (например, исправление данных при импорте неверных данных клиента или изменение всех 10 000 000 записей с одного клиента). другому клиенту, когда компания куплена конкурентом). Обычно разработчики приложений не

HLGEM
источник
Спасибо за ответ. Все процессы и типы приложений, о которых вы говорите, должны общаться с DAL (который, в свою очередь, будет содержать ограничения). НО! Ваша точка зрения идеальна, а ваш комментарий хорош. Sidenote: Да. Я склонен пытаться облегчить разработку. Для меня меньшая сложность может выдержать меньше способов поступить неправильно. Это не «хочу разрабатывать проще / быстрее», даже если это может быть - если он обрабатывается неправильно. Следовательно, почему я отправляю этот вопрос! Я также хотел бы видеть кого-то здравого смысла, если этот не каскад был выбран со смыслом, а не 100%, как в этом сценарии. Я должен выяснить причины.
Независимо
@Jonas, могут быть и причины производительности. Зависит от количества дочерних записей. Хорошо, если вы удаляете небольшие группы, но если могут сработать миллионы записей, вам лучше делать пакеты и не блокировать все таблицы, пока происходит весь процесс. Как правило, многие dbas не разрешают каскадное удаление только по этой причине, поскольку оно может заблокировать систему prod, если удаление затрагивает слишком много записей.
HLGEM
2
Нет, все процессы не должны общаться с DAL. Процессы ETL обычно не делают ни того, что должно произойти на уровне базы данных, которое влияет на многие записи, когда происходят большие изменения (например, выкуп клиента). Также вы не можете запретить кому-либо использовать окно запроса для одноразовых изменений. Я никогда не видел базы данных, в которой не было бы ограничений на уровне базы данных, у которых не было проблем с целостностью с течением времени.
HLGEM
10

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

Я твердо верю, что это единственная область разработки программного обеспечения, в которой вам не следует применять DRY (и я полностью ожидаю, что за это утверждение будет оказано огромное количество отрицательных голосов). Ваши данные - это сердце и душа вашего приложения - если оно когда-либо будет повреждено и не подлежит восстановлению, то оно: игра окончена. ИМО стоит применять ограничения везде, где они необходимы. Если это означает в форме триггеров и ограничений на уровне БД, проверки на стороне сервера в промежуточном программном обеспечении и Javascript на стороне клиента в пользовательском интерфейсе (для веб-приложений), то IMO - необходимое зло для обеспечения того, чтобы данные всегда были нетронутыми ,

Уэйн Молина
источник
6

Вы знаете, что означает ORM? Объектно-реляционное отображение. Цитирую Википедию "Техника для преобразования данных между несовместимыми системами типов". Да, реляционные и объектные модели не подходят друг другу. ORM делают довольно хорошее преобразование, соблюдая правила обеих систем типов. СУБД организованы таким образом, что вы достигаете целостности данных с помощью ограничений. В целом, целостность - это очень хорошая вещь, поэтому ORM склонны использовать их при создании модели данных для хранения данных объекта. У вашего ORM, вероятно, есть веская причина использовать «не каскадные» ограничения. И если это заставляет вас делать сложные запросы вместо того, чтобы просто создавать / обновлять / удалять определенные объекты, то что-то не так с вашей настройкой ORM.

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

Яцек Прусия
источник
Тема посвящена удалению функциональности ограничения из БД и использованию настроек / разработок в базе кода (например, .net говоря: Entity / Linq2Sql).
Независимо
Да, я знаю, но суть в том, что вам нужно сначала понять, почему существуют ограничения, а затем, почему их может быть плохой идеей.
Яцек Прусия
Переехал! Не упал. Я понимаю, что вы сожалеете о знании, о котором не было.
Независимо
Вы не можете ничего перемещать между несовместимыми системами. Вы будете отбрасывать ограничения БД, вводить ограничения приложений и просто надеяться, что они будут работать одинаково (что может оказаться как истинным, так и ложным). Во всяком случае, мои искренние извинения, если я неправильно понял ваш вопрос.
Яцек Прусия
Благодарность! «Движение» означает буквальное «движение». Это означает, что вы создаете (хорошее выражение) прикладные ограничения в каждой системе. По крайней мере, каждая система, которая не может использовать один и тот же DAL. Очень хороший пример - прямые запросы от администратора базы данных, которые «что-то исправляют». Никакие ограничения по БД и отсутствие знаний в области проектирования не могут привести к появлению потерянных данных или, к сожалению, к полностью смоделированным данным.
Независимо
6

Хорошо, это то, что сделал eBay, и у них, вероятно, есть одна из крупнейших баз данных в мире:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

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

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

Работая в среде разработки с сильной ссылочной целостностью, я знаю, что с точки зрения разработчика, это может быть полной болью; часто в среде разработки немного грязных данных не имеет значения, и разработка того, как удалить строку, может занять час или больше. Однако это также может быть очень полезным, так как ограничения делают схему явной.


источник
Наконец-то кто-то, кто меня понимает :-). Вы совершенно правы, баланс здесь действительно важен. Перемещение ограничений на уровень приложения может быть безопасной альтернативой, если это сделано в качестве стратегической точки. Было бы неплохо с некоторыми URL-адресами сайтов испытывать снижение производительности из-за жестких ограничений / целостности.
Независимо
10
Да, и не забывайте - не забывайте - что Ebay, как Facebook и Amazon, - это в миллиарды раз больше, чем 99,99% баз данных, и что хорошо для них, вероятно, сильно отличается от того, что хорошо для вашей базы данных.
Тони Эндрюс
2
И, возможно, Ebay, Facebook, Amazon не используют базы данных без ограничений для своего финансового и бухгалтерского программного обеспечения, своего программного обеспечения для инвентаризации или своих данных о людских ресурсах или где-либо, где потеря данных не имеет решающего значения.
HLGEM
2
Если у вас есть достаточно времени, опыта и денег, вы можете в конечном итоге запрограммировать любую СУБД, веб-сервер или операционную систему для удовлетворения конкретных потребностей.
JeffO
1
eBay не делал этого до тех пор, пока огромные объемы данных, с которыми они имели дело, существенно не превысили возможности серверов баз данных, и у них были миллионы, чтобы инвестировать в свою новую архитектуру. Если вы выполняете миллиарды транзакций в день, то непременно займитесь устранением ограничений и переходом к полностью основанной на очереди, не требующей транзакций, масштабируемой системе, такой как eBay. В противном случае не стоит недооценивать сервер базы данных и не оставлять базу данных подверженной повреждению данных, сняв все ограничения.
Крейг
4

Во-первых, мой ответ: нет, вы не должны полагаться только на приложение, чтобы следить за вашими данными.

Это указывает на более широкую дискуссию: ORM поощряют культуру презрения к «прямому» взаимодействию с БД, часто за счет нормализации / ссылочной целостности. Таблицы принудительно отображаются на произвольные иерархии объектов за счет дизайна, заложенного в реляционной модели. Разъединение, предпочитаемое ООП, возможно, здесь принесено в жертву, так как приложение позволяет почувствовать его дизайн в структуре данных. Хотя ORM продемонстрировал большую полезность, он, похоже, основан на злоупотреблении или недоверии к SQL.

Новые парадигмы (вновь) появляются, например, функциональное программирование. Если команда разработчиков решит использовать новую методологию программирования, как это повлияет на данные, структурированные в соответствии с требованиями ORM?

Я согласен с @Jacek Prucia - я думаю, что ORM плохо подходит для RDBMS, я бы лично выбрал DBAL в RDBMS или пошел бы на OODB с ORM.

sunwukung
источник
+1 за говорящие альтернативы теме. Другая сторона дискуссии, конечно же: «Насколько плохи будут некоторые данные?» и ответом может быть отмена или миллиардное внесение денег на чей-то банковский счет на миллион долларов. А также некоторые потерянные данные, которые удаляются с помощью хороших процедур очистки. Краткое содержание этой темы выглядит как соответствие стоимости гибкости. Что, в свою очередь, полностью зависит от серьезности содержания и использования БД.
Независимо
3

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

Кроме того, допустим, что ваше приложение необходимо переписать, но с той же базой данных. Все эти ограничения в коде - всего лишь попрошайничество об ошибках, которые препятствуют некоторому вводу, в то же время пропуская ошибочные данные.

При разработке, будьте проще. Ограничения позволяют вам сделать это. (Тем не менее, когда ограничение выдает ошибку, не выкладывайте ту же ошибку обратно на пользователя. Сделайте эту ошибку понятной.)

(Что касается каскадной проблемы: это хорошо. Я бы предпочел выдать ошибку, что некоторые другие записи должны быть удалены в первую очередь, а не полагаться на каскад, чтобы все было правильно. Каскады хороши в теории, но не обязательно так на практике.)

Керри Шоттс
источник
2

Одна проблема с ограничениями в базе данных состоит в том, что они дают программе ограниченную информацию о том, что не удалось и как это исправить. Это означает, что для бесперебойной обработки часто необходимо повторить проверку ограничений в приложении, и поэтому проверка ограничений базы данных является напрасной тратой усилий.

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

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

Поэтому, чтобы обойтись без ограничений базы данных, необходимо заранее определить, что можно и что нельзя делать с базой данных, чтобы все приложения могли быть написаны, рассмотрены и тщательно протестированы. Все требования к базе данных должны быть установлены заранее, и любое изменение требований к базе данных потребует обширной работы. Это методология замороженного водопада, которая работает только в очень специфических случаях. (Разработка, реализация и соблюдение требований очень похожи на хождение по воде. Сначала нужно что-то заморозить, и если этого не достаточно, результаты могут быть катастрофическими.)

Одним из случаев, когда это работает, являются крупные корпоративные приложения, такие как PeopleSoft и SAP, где приложение уже делает практически все, и есть тщательно определенные способы его расширения. Есть и другие, очень редкие возможности.

Так что, если вы не работаете над очень крупным корпоративным проектом (а я бы не хотел) или не можете ходить по жидкой воде, оставьте эти ограничения в базе данных.

Дэвид Торнли
источник
1
Спасибо за ответ. Ограничения будут в БД для этого проекта! Я полностью убежден :). У меня также будут более широкие глаза, когда я приму решение о будущих проектах и ​​при обсуждении других частей.
Независимо
1
Также учтите, что без ограничений вы оставляете это на усмотрение самого кода приложения, чтобы обнаружить, что оно облажалось. Это тот же код приложения, который нарушил ограничение в вашем примере, кстати, ограничение, которое спасло вашу базу данных от несогласованности или повреждения данных. Между прочим, использование ограничений не означает автоматического снижения производительности, а отсутствие ограничений оставляет базу данных открытой, поэтому она не может защитить себя.
Крейг