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

цель

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

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

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

идея

если EAV был нормализованный, он будет уродливым.

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

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

графы

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

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

вывод

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

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

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

пример проблемы

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

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

    • вопросы

    "какие проблемы вы пытаетесь решить?"
    - Пит!--14-->

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

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

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

13
data-structures database-design graph language-agnostic relational-database

4 ответов

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

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

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

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

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

"сильно взаимосвязанный" не является проблемой вообще. Такова природа реляционной базы данных. Нюанс здесь есть, это должно быть действительно нормальная, а не сборище inlerlinked плоских файлов.

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

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

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

5

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

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

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

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

Клиент Накладная InvoiceLineItem Продукт

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

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

4

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

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

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

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

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

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

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

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

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

дополнительное соглашение

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

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

2