Схема базы данных для исследовательского объекта

Question

Я разрабатываю схему базы данных для исследовательского объекта. База данных должна хранить экспериментальные образцы с преимущественно предопределенными (зависимыми или независимыми) переменными, но может потребовать переменные проекта, которые неизвестны до даты создания базы данных.

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

В настоящее время я рассматриваю два подход:

1. данные Хранить в wide data structure, то есть несколько 3NF нормализованные таблиц были столбцы представляют переменные (зависит/независимые), и каждую строка представляет собой образец.
2. Entity–attribute–value model/событие ориентировано, то есть каждое записанное значение сохраняется как событие.

Можете ли вы рекомендовать любой из этих подходов или других подходов к такому сценарию? Большое вам спасибо за ваши ответы.

Answer 1

Ни один из этих подходов не будет полностью работать ... С вашим подходом 1 вы не можете добавлять новые переменные, и в то время как ваш подход 2 будет работать, это будет не очень удобно с точки зрения гибкости и удобочитаемости ... также, Продвинутые пользователи должны иметь возможность использовать базу данных через SQL для анализа данных, «это будет очень сложно с этим подходом.

Возможно, лучший компромисс состоит в том, чтобы сделать немного и сохранить все переменные, которые в настоящее время известны как столбцы, а затем иметь отдельную таблицу атрибутов EVA (Entity Value Attribute), в которую могут быть добавлены пользовательские переменные. Это удерживает большую часть логики в хорошем состоянии, позволяя при необходимости динамические переменные. Если есть верхний предел количества добавляемых переменных, вы можете рассмотреть гибридный подход, например, SpareDateVariable1Name, SpareDateVariable1Value, SpareIntegerVariable1Name, SpareIntegerVariable2Name в таблице, чтобы добавить некоторые пользовательские переменные без использования

Основная проблема заключается в том, что в реляционных базах данных вы должны знать все столбцы вверх. Так они были разработаны. Вам следует рассмотреть возможность использования решения NoSQL, такого как MongoDB, которое хранит записи как «документы» без строгой схемы, так как просто нет способа решить это в традиционной реляционной базе данных, однако эти типы баз данных будут лучше справляться с этим сценарием.