Как сохранить таблицу данных (или List <KeyValuePair <int, Object >> или Dictionary) в базе данных?

В зависимости от базы данных Entity Framework и базы данных PostgreSQL мы пытаемся смоделировать часть данных, которые в основном состоят из списка ссылок на объект с именем OtherObject, который имеет идентификатор. Данные, которые мы пытаемся сохранить, это MyObject и состоит из Id и двух списков (с максимальной длиной 12) одной или нескольких ссылок на OtherObject и количества OtherObject s. Поэтому мы хотим хранить данные (например, отдельную таблицу и столбцы), которые коррелируют с этим:

FirstPattern:
OtherObject with ID 1, 10 times
OtherObject with ID 4, 12 times

SecondPattern:
OtherObject with ID 2, 2 times
OtherObject with ID 3, 4 times
OtherObject with ID 4, 11 times

Чтобы сделать это, мы подумали, что ICollection of KeyValuePair будет уместным. Таким образом, у нас есть список, который имеет значение (количество) для каждого ключа (OtherObject).

Модель выглядит следующим образом:

public class MyObject
{
    public int Id { get; set; }
    public IDictionary<OtherObject, int> FirstPattern { get; set; }
    public IDictionary<OtherObject, int> SecondPattern { get; set; }
}

Вопрос в том, как мы можем сохранить этот ICollection из KeyValuePair в базе данных? Нам также интересно, если это лучший способ сделать это.

Мы надеемся услышать это, если у вас есть (лучший) способ сохранить эти данные в базе данных! Спасибо за внимание.

ОТВЕТЫ

Ответ 1

Есть два типа, особенно подходящих для хранения словарей в целом: hstore и json - или в основном превосходящий jsonb в Postgres 9.4 +.

Postgres также имеет выделенный xml тип данных (как упомянутый в комментариях к DJ KRAZE), но я предпочел бы выбрать один из первых трех вариантов. XML является сравнительно многословным и более сложным (не сказать свернутым) и может быть излишним для вашей цели.

Если все, что вы хотите от БД, это хранить и извлекать весь словарь, это хорошие варианты.
Подробности и ссылки в этом связанном ответе на dba.SE:

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

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

Нормализованный макет таблицы

Из того, что я собираю, "MyObject" (m) содержит набор ссылок на "OtherObject" (o). Каждый m связан с (24) o, и каждый o связан с 0-n m - который может быть реализован в классическом соотношении n: m. Вот подробные инструкции: