Пользовательские схемы данных для приложений

Question

Я хочу написать приложение, которое позволяет пользователям определять свои собственные схемы базы данных. Пользователь предоставляет определение с использованием DSL (биологических экспериментов), и на основе этого создается модель отношения oop/entity. Бэкэнд должен быть РСУБД, такой как Postgres.

Каков наилучший способ для этого?

Я вижу два возможных пути у верхней части моей головы: типы

1. Карта для таблиц SQL так же, как вы бы при написании Django или Hibernate приложения на основе. Затем объекты сопоставляются строкам таблицы.
2. Опишите типы в таблице «тип» и объектах в другой таблице.

Что здесь вообще делают люди? Для 1. управление разрешениями и т. Д. Может быть передано rdbms. Однако как можно отслеживать изменения здесь и разрешать откаты?

Может ли кто-нибудь указать мне на лучшую практику?

Answer 1

Лучшая практика во многом зависит от конкретных потребностей вашего приложения. Например, вариант 1 подходит, если вы пишете генератор приложений с технически подкованными и надежными пользователями. Это, например, подход, применяемый PeopleSoft Application Designer. Отслеживание изменений и разрешение откатов является сложным, так как вы не можете отбросить что-то вроде отброшенного столбца. Вы могли бы написать сложную схему с настраиваемой таблицей аудита, чтобы отслеживать, что было сделано, и логикой, чтобы сделать ее обратимой. Но вы все равно потеряете данные с этим столбцом. Если хранилище не вызывает беспокойства, вы можете сделать резервную копию таблицы с каждым изменением, а откат просто восстановит эту резервную копию. Но тогда вы рискуете потерять данные, которые были добавлены в таблицу между изменением и откатом.

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

Answer 2

Есть много вариантов, на самом деле путь больше, чем вы предлагаете.

Не делать вариант 1 Динамическое создание таблиц/схем действительно странно, за исключением случаев, когда вы пишете общий клиент базы данных, например TOAD или RAD. Не похоже, что это то, что вы хотите построить, но если просто используете один из существующих. Конечно, вы могли бы создавать все классы, отображая информацию и сценарии динамически, но с какой целью? Вы должны использовать их, используя рефлексию, так как они не существуют, когда вы пишете свою программу.

Не используйте СУБД Идея создания РСУБД заключается в том, что она имеет более или менее фиксированную схему. Если это не соответствует вашим потребностям, не делайте этого. Используйте что-то более динамичное. База данных NoSql, такая как MongoDb, может соответствовать вашим потребностям. Если откат действительно важен, вы можете использовать репозиторий git в качестве backend.

Возможно, это хранилище данных? Вы говорите о «экспериментах».Поэтому, если вам нужно хранить измерения, это может быть просто: измерения, и у них будет тип и эксперимент, к которому они принадлежат ... немного похоже на вариант 2. Чтобы узнать больше об этом, вам может понадобиться посмотреть " звездные схемы "