Есть ли какая-либо причина для создания ограничений между таблицами (внутри SQLserver) в настоящее время? Если да, то когда? Большинство приложений в моей области построены на объектных принципах, а таблицы объединяются по требованию. Спрос основывается на потребности из приложения. Я не буду загружать связку ограниченных таблиц для простого поиска, который, в свою очередь (после действия), потребует еще одного простого поиска.
Инструменты ORM, такие как EntityContext, Linq2Data, NHibernate, также сами обрабатывают ограничения, по крайней мере, вы знаете, какие таблицы нужны друг другу. Делать ограничения внутри сервера - это просто делать (заставлять) одни и те же изменения дважды?
Обычно это не вопрос для принятия решения, но эта база данных разработана совершенно по-другому. Дизайн выглядит хорошо, в основном отражает объекты, используемые приложениями. Меня беспокоит то, что все ограничения, сконфигурированные внутри SQLserver с «не каскадом». Это означает, что вы должны играть «искать и находить» при кодировании новых запросов к базе данных. В некоторых случаях требуется до 10 уровней точного порядка, чтобы сделать одно удаление.
Это удивляет меня, и я не уверен, как справиться с этим.
В моем простом мире этот параметр заставляет ограничения терять большую часть цели. Хорошо, если к базе данных обращались с хостов без знания дизайна.
Как бы вы действовали в этом сценарии?
Почему бы просто не удалить все ограничения из БД и сохранить их на уровне приложения?
источник
Ответы:
Две основные причины не удалять ограничения из БД :
Ваш конкретный случай звучит так, как будто схема БД изначально была сгенерирована инструментом ORM (или разработана кем-то, не имеющим большого опыта работы с реляционным миром), поэтому она неоптимальна с точки зрения отношений. Вероятно, лучше проанализировать и улучшить его в сторону более «естественного» реляционного дизайна, сохраняя его в соответствии с представлениями ORM. В этом анализе может быть полезно привлечь эксперта по БД.
источник
Приложения могут приходить и уходить, но данные живут вечно. В моей компании БД старше 30-40 лет, она будет жить до тех пор, пока компания существует. Приложения меняются, разработчики приходят и уходят. Лучше иметь целостность и хорошую логическую модель данных. Таким образом, кто-то может смотреть на данные и получать осмысленное понимание без необходимости проходить сложную кодовую базу. Это также помогает в отчетности значительно. Кроме того, приложения могут и будут иметь ошибки, и ограничение БД является защитой от этого. Моя позиция по умолчанию - иметь как можно больше ограничений (FK и check).
Единственная причина, по которой не будет ограничений, заключается в том, что ваш шаблон проектирования не допускает этого, например, проблемы с таблицей в иерархии или проблемами с производительностью.
источник
Это не беспокоит меня, это означает, что кто-то проявил здравый смысл. Каскадные удаления часто очень вредны для базы данных. Во-первых, иногда вы хотите, чтобы удаление не удалось, если у вас есть данные в связанных таблицах. Например, если у вас есть клиент, у которого есть заказ в прошлом, вы не хотите, чтобы он был удален, или вы теряете данные о том, для кого был заказ, и каскадное удаление избавит вас от записи, которая испортит вам финансовую отчетность. ,
Вы, кажется, думаете, что легкость разработки - это самая важная вещь. В мире баз данных это просто неправда. Целостность данных - это самая важная вещь, за которой следуют производительность и безопасность данных. Если для написания запросов требуется больше времени, пусть будет так.
База данных обычно используется многими приложениями = одним или несколькими веб-сайтами или настольными приложениями, приложением для создания отчетов, веб-службами, окном запросов, процессами ETL и т. Д. Если вы не применяете ограничения на уровне базы данных, вы сначала теряете целостность данных, поскольку одно из этих приложений может не соответствовать всем правилам. Во-вторых, вы должны кодировать эти противоречия несколько раз и переписывать их, если позже решите использовать другое приложение. В-третьих, вы не можете заранее контролировать, будет ли необходимость выполнять какую-то задачу обслуживания данных, которая не будет выполняться через приложение (например, исправление данных при импорте неверных данных клиента или изменение всех 10 000 000 записей с одного клиента). другому клиенту, когда компания куплена конкурентом). Обычно разработчики приложений не
источник
Я где-то читал, что в основном говорится: данные - это ключ вашего приложения . Если вы когда-либо будете получать доступ к данным только через ваш пользовательский интерфейс (и я имею в виду , как всегда , так и сейчас, навсегда ... или жизнь вашего приложения, во всяком случае), тогда вам не нужны ограничения базы данных. Но есть вероятность, что что-то, кроме самого приложения, должно будет касаться данных, например, веб-службы, общедоступного API, задачи rake / задания SQL / cron / автоматизированного сценария, и тогда вы избавите себя от множества потенциальных неприятностей. дорога, соблюдая ограничения БД.
Я твердо верю, что это единственная область разработки программного обеспечения, в которой вам не следует применять DRY (и я полностью ожидаю, что за это утверждение будет оказано огромное количество отрицательных голосов). Ваши данные - это сердце и душа вашего приложения - если оно когда-либо будет повреждено и не подлежит восстановлению, то оно: игра окончена. ИМО стоит применять ограничения везде, где они необходимы. Если это означает в форме триггеров и ограничений на уровне БД, проверки на стороне сервера в промежуточном программном обеспечении и Javascript на стороне клиента в пользовательском интерфейсе (для веб-приложений), то IMO - необходимое зло для обеспечения того, чтобы данные всегда были нетронутыми ,
источник
Вы знаете, что означает ORM? Объектно-реляционное отображение. Цитирую Википедию "Техника для преобразования данных между несовместимыми системами типов". Да, реляционные и объектные модели не подходят друг другу. ORM делают довольно хорошее преобразование, соблюдая правила обеих систем типов. СУБД организованы таким образом, что вы достигаете целостности данных с помощью ограничений. В целом, целостность - это очень хорошая вещь, поэтому ORM склонны использовать их при создании модели данных для хранения данных объекта. У вашего ORM, вероятно, есть веская причина использовать «не каскадные» ограничения. И если это заставляет вас делать сложные запросы вместо того, чтобы просто создавать / обновлять / удалять определенные объекты, то что-то не так с вашей настройкой ORM.
Если вы считаете реляционную концепцию раздражающей, то почему вы не используете объектную базу данных? Некоторое время назад они были медленными (именно поэтому большинство людей все еще используют RDBMS), но из того, что я слышал, все немного изменилось. Вы бы избавились от всех ролевых щупалец. Просто возражает, возражает.
источник
Хорошо, это то, что сделал eBay, и у них, вероятно, есть одна из крупнейших баз данных в мире:
http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
Несмотря на то, что было сказано выше о производительности, которая увеличивается за счет ссылочной целостности, она может фактически ухудшаться; именно поэтому массивные базы данных снимают свои ограничения и выполняют работу на прикладном уровне. И, насколько я могу судить, это единственная действительно веская причина.
Отбросив эти ограничения, вы фактически потеряете свою сеть безопасности, которая поддерживает чистоту данных и порождает собственные проблемы. Как и во всем, это уравновешивание. Я предполагаю, что в целом поддержание ссылочной целостности - правильная вещь.
Работая в среде разработки с сильной ссылочной целостностью, я знаю, что с точки зрения разработчика, это может быть полной болью; часто в среде разработки немного грязных данных не имеет значения, и разработка того, как удалить строку, может занять час или больше. Однако это также может быть очень полезным, так как ограничения делают схему явной.
источник
Во-первых, мой ответ: нет, вы не должны полагаться только на приложение, чтобы следить за вашими данными.
Это указывает на более широкую дискуссию: ORM поощряют культуру презрения к «прямому» взаимодействию с БД, часто за счет нормализации / ссылочной целостности. Таблицы принудительно отображаются на произвольные иерархии объектов за счет дизайна, заложенного в реляционной модели. Разъединение, предпочитаемое ООП, возможно, здесь принесено в жертву, так как приложение позволяет почувствовать его дизайн в структуре данных. Хотя ORM продемонстрировал большую полезность, он, похоже, основан на злоупотреблении или недоверии к SQL.
Новые парадигмы (вновь) появляются, например, функциональное программирование. Если команда разработчиков решит использовать новую методологию программирования, как это повлияет на данные, структурированные в соответствии с требованиями ORM?
Я согласен с @Jacek Prucia - я думаю, что ORM плохо подходит для RDBMS, я бы лично выбрал DBAL в RDBMS или пошел бы на OODB с ORM.
источник
Ограничения - ваша единственная гарантия того, что у вас есть согласованность и целостность данных на уровне базы данных. Конечно, вы можете применять ограничения, используя код приложения, но что если в будущем вам нужно будет изменить данные напрямую? Вы можете понять, как сохранить целостность данных, но кто-то другой может этого не сделать. Сохранение ограничений на уровне данных обеспечивает целостность, даже когда кто-то возится в местах, которые он не понимает.
Кроме того, допустим, что ваше приложение необходимо переписать, но с той же базой данных. Все эти ограничения в коде - всего лишь попрошайничество об ошибках, которые препятствуют некоторому вводу, в то же время пропуская ошибочные данные.
При разработке, будьте проще. Ограничения позволяют вам сделать это. (Тем не менее, когда ограничение выдает ошибку, не выкладывайте ту же ошибку обратно на пользователя. Сделайте эту ошибку понятной.)
(Что касается каскадной проблемы: это хорошо. Я бы предпочел выдать ошибку, что некоторые другие записи должны быть удалены в первую очередь, а не полагаться на каскад, чтобы все было правильно. Каскады хороши в теории, но не обязательно так на практике.)
источник
Одна проблема с ограничениями в базе данных состоит в том, что они дают программе ограниченную информацию о том, что не удалось и как это исправить. Это означает, что для бесперебойной обработки часто необходимо повторить проверку ограничений в приложении, и поэтому проверка ограничений базы данных является напрасной тратой усилий.
Это рискует поставить под угрозу целостность данных, поэтому у нас здесь есть компромиссы. Для важных данных обеспечение целостности данных почти всегда важнее производительности, и гораздо лучше провалить транзакцию, даже если она выглядит произвольно, чем испортить данные.
Поэтому для безопасного удаления ограничений жизненно важно обеспечить доступ к базе данных, чтобы ничто не могло изменить базу данных без проверки ограничений. Это ненадежно при написании новых приложений или разработке специальных способов работы с данными, поскольку все, что требуется, - это одна ошибка, а база данных повреждена.
Поэтому, чтобы обойтись без ограничений базы данных, необходимо заранее определить, что можно и что нельзя делать с базой данных, чтобы все приложения могли быть написаны, рассмотрены и тщательно протестированы. Все требования к базе данных должны быть установлены заранее, и любое изменение требований к базе данных потребует обширной работы. Это методология замороженного водопада, которая работает только в очень специфических случаях. (Разработка, реализация и соблюдение требований очень похожи на хождение по воде. Сначала нужно что-то заморозить, и если этого не достаточно, результаты могут быть катастрофическими.)
Одним из случаев, когда это работает, являются крупные корпоративные приложения, такие как PeopleSoft и SAP, где приложение уже делает практически все, и есть тщательно определенные способы его расширения. Есть и другие, очень редкие возможности.
Так что, если вы не работаете над очень крупным корпоративным проектом (а я бы не хотел) или не можете ходить по жидкой воде, оставьте эти ограничения в базе данных.
источник