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

Цель

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

Проблема

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

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

Идея

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

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

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

Графики

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

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

Заключение

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

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

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

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

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

• Многие свойства , которые могут быть не просто строками, а целыми объектами.
• В мире библиотек нет простой (и реляционной) схемы, которая может хранить данные «без потерь» без чрезвычайно сложных схем.
• Множество различных типов ассоциаций и связанных объектов Что мне не хватает?

  ---

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

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

  • Многие свойства , которые могут быть не просто строками, а целыми объектами.
  • В мире библиотек нет простой (и реляционной) схемы, которая может хранить данные «без потерь» без чрезвычайно сложных схем.
  • Множество различных типов ассоциаций и связанных объектов Что мне не хватает?

    ---

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

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

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

    ---

    Вопросы

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

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

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

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