Каков наилучший способ хранения пользовательских объектов в реляционной базе данных?

Question

У меня есть мои объекты со своими свойствами. Объекты могут изменять свою структуру: свойства могут быть добавлены/удалены/изменены. Объекты могут быть абсолютно сброшены. Таким образом, метаданные объекта (описание, классы, назовите их так, как вы хотите :)) могут быть изменены.

В базе данных должны храниться схемы объектов и экземпляры этих объектов.

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

В настоящее время я вижу только два пути:

1. хранить объекты схемы в нескольких таблицах: общие данные схемы, свойства схемы, возможные типы свойств. Храните экземпляры в своих таблицах: общие данные экземпляра, несколько таблиц - для каждого типа из таблицы возможных свойств, чтобы хранить данные свойств экземпляра. И так далее.
2. схемы объектов объектов, как в p1, но хранят экземпляры, такие как XML-файлы в одной таблице: одна таблица для общей информации об экземпляре и одна таблица с экземпляром XML.

пожалуйста, не спрашивайте почему/за что мне это нужно. Просто нужно хранить пользовательские объекты, и БД должна работать быстро :)

Answer 1

Сериализация. В Java, буквально, Serialize. В Python рассол. На других языках используйте все, что у них получилось. Сохраните результаты в столбце blobby. Выходите на пиво.

Answer 2

Я бы сохранил схему как блок XML и данные как еще один блок XML. Вы можете легко сериализовать/unserialize это, и есть стандарты для XML-схем уже.

Если вам нужно индексировать некоторую часть данных для быстрого извлечения, я бы вытащил эту информацию в дополнительные столбцы, по которым вы можете индексировать. Но, конечно, сохраните XML-блобы.

Answer 3

Я буду использовать .NET (C# в частности). И я должен использовать реляционную базу данных для проекта.

Если у меня есть миллионы экземпляров, как это замедлит работу базы данных, если я захочу использовать BLOB (p2 из моего списка выше)? Будет ли сохранение BLOB лучше с точки зрения производительности?

Answer 4

С реляционной БД есть несколько вариантов.

1. Сериализация в BLOB - не подходит, , поскольку вы не можете искать объекты.
2. Есть таблица для метаданных и таблицы с такими столбцами, как Property1 .. СвойствоN - довольно быстро, но не совсем гибкое.
3. Если вы не должны схемы изменения часто вы можете пойти с реальных таблиц для объектов (например, действительно делает CREATE TABLE, ALTER TABLE и т.д.).

Помимо реляционных БД вы можете попробовать NoSQL db, например. mongodb. Я только что провел несколько тестов, и коллекция с объектами 5M работает достаточно быстро. Очевидно, что решение NoSQL не вписывается в ваше требование relational, но если у вас есть время, просто попробуйте.