Хранение графиков в полностью нормализованных реляционных базах данных.

Question

Цель

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

---

Задача

EAV - это обходной путь к нормальным ограничениям СУБД.

Если бы вы нормализовали схему EAV, это было бы ужасно.

---

Идея

Если бы EAV нормализовался, это было бы ужасно.

Ограничивает ли тот факт, что мы традиционно поддерживаем эти схемы вручную, их сложность и мощность?

Но если это будет поддерживаться и запрашиваться программно, какое это имеет значение?

---

Графы

Если у вас n разные сущности в n разных таблицах, почему бы не позволить вашему коду генерировать n(n+1)/2 таблицы ссылок и запросы между ними? Не приведет ли это к истинному графу в нормализованной схеме?

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

---

Заключение

Может ли система нормализовать EAV и поддерживать полученную сложную схему?

Могут ли сложные графики храниться (и оставаться верными) в реляционных базах данных?

Я уверен, что это было сделано раньше, но я никогда не видел это. Чего мне не хватает?

---

Пример задачи

Хранение печатных произведений и их библиографических данных

• Множество свойств , которые могут быть не просто строками, а целыми объектами.
• В мире библиотек не существует простой (и реляционной) схемы, которая может хранить данные "без потерь" без чрезвычайно сложных схем.
• Множество различных типов ассоциаций и связанных объектов
  • И их соответствующие свойства (которые могут сильно различаться).
  • И их многочисленные взаимоотношения разных типов между собой.

---

Вопросы

" Какую проблему вы пытаетесь решить? "
-Piet

Я ищу нормализованное решение для EAV, графиков и полиморфных отношений в системе реляционных баз данных.

" Я бы не хотел быть парнем, который должен понимать или поддерживать его после того, как он будет запущен в производство. "
-Эндрю

Это "традиционное обслуживание" - это именно то, о чем я говорю, мы должны автоматизировать. Разве это не в значительной степени грубая работа?

Answer 1

Поскольку вы редактируете вопрос, он должен быть активным.

Да, есть гораздо лучшие способы его разработки для описанной цели и использования.

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

Вы должны рассмотреть правильную академическую альтернативу.Это восстанавливает полную реляционную целостность и возможности.Это называется шестой нормальной формой.EAV на самом деле является подмножеством 6NF, без полного понимания;наиболее широко известное воспроизведение 6NF.

6NF, реализованное правильно, особенно быстро, в нем хранятся столбцы, а не строки.Таким образом, вы можете отобразить ваши данные (ряды графиков, точки данных) таким образом, чтобы получить постоянную высокую скорость независимо от векторов, которые вы используете для доступа к графикам.(Вы можете исключить дублирование до более высокого порядка, чем 5NF, но это расширенное использование.)

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

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

Мои ответы на эти вопросы обеспечивают полное рассмотрение предмета.Последнее особенно длинное из-за контекста и аргументов.
EAV-6NF Ответ один
EAV-6NF Ответ два
EAV-6NF Ответ Три

И этот вопрос также стоит:
Связанный со схемойПроблема

Answer 2

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

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

В вашем сценарии всегда будет большое количество путей от одного объекта к другому. Как кто-то узнает, какой путь был «правильным». «Правильный» путь будет просто «набором отношений, которые разработчик выбрал для заполнения».

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

Клиент <===> Счет-фактура <===> InvoiceLineItem <====> Продукт

Если я посмотрю на это, и кто-нибудь спросит меня: «Дайте мне список клиентов, а для каждого клиента - список продуктов, которые они купили», я бы знал, как написать запрос.

Но если это был график, где все указывало на все остальное, как я узнаю, какой путь является «правильным» путем. Будет ли это отношение «Customer_Product», «Customer_Invoice_Line_Item» к «Customer_Product» или «Customer_Invoice» к «Invoice_Product» или от «Customer» к «Invoice» к «Invoice_Line_Item» к «SomeOtherTableIHaven'tEvenLookedAtYet» к «Product» Ответ может быть «Это должно быть очевидно», но очень часто что-то очевидно для одного разработчика.

Answer 3

почему бы не позволить вашему коду генерировать n (n + 1) / 2 "ссылочных" таблиц и запросы между ними?

Каждый раз, когда я вижу что-то в области компьютерных наук, где ответвыходит «примерно в n-квадрате», я сразу думаю, что ответ неправильный.: -)

Но более реалистично, когда "n" становится умеренным размером, количество таблиц ссылок становится огромным, действительно, очень быстрым.Настолько, что вы не можете сказать, что эта методология может представлять собой универсальное решение, IMO.

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

• Вы теряете возможность иметь обнаруживаемую схему - количество таблиц выходитруки так быстро, любой, кто смотрит на ваш дизайн стола, не может знать, каковы отношения.
• База данных не может обеспечить почти никакой целостности данных, кроме самого базового ссылочного вида - весь код, который использует базу данных, должен быть осторожен, чтобы не нарушать правила, иначе выесть повреждение данных.
• Возможно, у вас будет очень большое количество таблиц, которые моделируют отношения, которые на самом деле не существуют в вашей бизнес-сфере.Когда вы используете таблицу «ссылок», вы, по сути, моделируете отношения «многие ко многим», которые могут существовать или не существовать в реальном мире.
• Потенциально вы теряете огромное количество скорости и получаете оченьбольшой штраф с точки зрения хранения используется.Гораздо эффективнее моделировать отношения 1: N, ссылаясь непосредственно на «родительский» объект в «дочернем» объекте.

Answer 4

Это полностью зависит от определения вашего графика.

Единственный «истинный» способ хранения графа, в базе данных отношений или иным образом, - это простой список смежностей (или один из его вариантов). Все остальное является производной, специализацией или оптимизацией этого метода и зависит от знания предметной области.

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

Я уверен, что это было сделано раньше, но я никогда не видел это. Чего мне не хватает?

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

Добавление

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

Я думаю, что это гораздо чаще, чем вы думаете. Я в основном знаком с Python, но все основные доступные для него инструментарии ORM / RDBMS (SQLAlchemy, Django, SQLObject, ...) поддерживают автоматическое обслуживание таблиц ссылок «многие ко многим» в качестве стандартной функции.