Зачем нужны реляционные базы данных?

Question

Специально для веб-приложений

(1) почему отношения (т.е. внешние ключи) в СУБД даже полезны?

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

Кроме того, если бы я поместил всю необходимую логику проверки полей в СУБД (т. Е. MySQL), она просто вернула бы неопределенную ошибку. По крайней мере, с помощью проверки на основе PHP я знаю, какое поле отсутствует, и я могу уведомить пользователя (хотя с проверкой на основе Javascript это почти никогда не произойдет).

(2) Был ли в прошлом момент, когда СУБД были по какой-то причине полезны или есть причина, по которой они полезны сейчас, о которой я не знаю?

Мне действительно нужно некоторое понимание этой темы. Я просто не могу придумать хороший ответ.

Answer 1

Я подойду к этому под другим углом.

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

Проблема в том, что у нас не было стандартного слоя данных (например, объектно-реляционного отображения) поверх базы данных. У нас было несколько программных источников, которые подавались в одни и те же таблицы. Это было забавно, потому что через некоторое время вы могли сказать, какие части кода создали какие строки в таблице. Иногда ссылки выстраиваются, иногда нет. Иногда ссылки были NULL (когда их не должно быть), а иногда их было 0. У нас даже было несколько циклических записей, что было забавно.

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

Answer 2

Я не большой любитель SQL, но даже должен сказать, что у реляционной структуры есть свои преимущества.

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

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

Answer 3

"Я не вижу реального использования внешних ключей и, следовательно, никакого реального использования для реляционных баз данных"

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

Ограничение внешнего ключа - это всего лишь один вид ограничения целостности данных.Конечно, вы можете реализовать правила целостности вне базы данных, но СУБД спроектирована и оптимизирована, чтобы выполнять эту работу за вас, и, как правило, является наиболее эффективным местом для ее выполнения, поскольку она наиболее близка к структурам данных.Если бы вы сделали это за пределами базы данных, у вас была бы как минимум дополнительная поездка туда и обратно для получения необходимых данных.Вам также придется реплицировать модель блокировки / параллелизма СУБД в коде вашего приложения.

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

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

Различные инструменты CASE и инструменты DBA воспользуются преимуществами ограничений базы данных, смогут перепроектировать их и использовать их для содействия задачам разработки и обслуживания.

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

Answer 4

(1), почему отношения (т.е. внешние ключи) в СУБД даже полезны? Во-первых, я думаю, что вы говорите о внешних сдерживающих факторах. Внешние ключи - это просто логическая конструктивная особенность, которая говорит о том, что этот объект совпадает с этим.

Полезны ограничения внешнего ключа:

• Они помогают вам придерживаться принципа СУХОЙ (не повторяйтесь). Конечно, ваше приложение проверяет отношения, но делает ли оно это в нескольких местах? Есть ли несколько приложений, которые обращаются к одной и той же БД? Нужно ли повторять логику в каждом приложении? Эй, вы могли бы вытащить эту логику и использовать общую DLL для доступа к этим данным, которая усиливает эту логику. Еще лучше, что, если это встроено в RDMBS, чтобы мне не пришлось писать собственный код, чтобы сделать что-то такое рутинное? Bam. Ограничения внешнего ключа.

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

Что касается неопределенной ошибки. Разве ваш аргумент не был бы лучше сформулирован, поскольку СУБД X имеет неопределенные ошибки, когда данные не проходят проверку ограничений внешнего ключа? Как бы вы это ни обобщали, вы также можете утверждать, что мы должны использовать бумажные книги вместо компьютеров, потому что ограничение содержало неопределенную ошибку.

(2) Был ли в прошлом момент, когда СУБД были по какой-то причине полезны или есть причина, по которой они полезны сейчас, о которой я не знаю? Да, это было бы сейчас, вчера и, вероятно, надолго в будущем.

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

Answer 5

СУРБД все еще очень полезны.Не уверен, почему ты так не думаешь.Ограничения внешнего ключа могут использоваться для поддержания ссылочной целостности (другими словами, для обеспечения простого способа выражения отношений 1: 1, 1: много и много: много. СУБД также полезны, поскольку в отличие от практических разработок существовала богатая теория, сопровождающая практические разработки.предыдущие СУБД. В частности, реляционное исчисление / алгебра хороши, так как они обеспечивают хорошую оптимизацию запросов, нормализацию и т.д.

Answer 6

Одной из невероятно полезных функций внешних ключей в большинстве реляционных баз данных являются каскады.

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

Если у вас нет этого ограничения, вы должны справиться с этой ситуацией самостоятельно, в своем собственном коде.

Answer 7

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