Проектирование базы данных - одна таблица с несколькими полями, много таблиц с одним полем или абстрактные таблицы? - PullRequest
1 голос
/ 23 апреля 2011

Мне нужно спроектировать схему для хранения объектов, которые имеют много свойств, но мало общих.

Я нашел здесь несколько решений, но я все еще не убежден в том, что лучше всего сделать.Я вижу четыре способа сделать это:

  1. Одна таблица со многими полями: это может привести ко многим NULL значениям, и непростое время, когда возникает необходимость добавить некоторые свойства или изменить некоторые типы данных.
  2. Создание новой таблицы для каждого свойства: это упрощает добавление и обновление столбцов и сохраняет возможности поиска, хотя каждый SELECT приведет к большому количеству JOIN.
  3. Созданиетаблица для каждого типа свойства, например: теги, количества, интервалы и т. д. Я не уверен в этом случае, если мне нужно различать числа с плавающей запятой, десятичные числа, целые числа и т. д.
  4. Создание абстрактных таблиц (я читаю здесь, это называется шаблоном наблюдения), в которых хранятся имя свойства и тип данных.

Каким критериям мне следует следовать, на какие вопросы я должен ответить, чтобы выбрать между этими решениями?

Спасибо

Ответы [ 2 ]

1 голос
/ 23 апреля 2011

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

Вообще, я предпочитаю абстракцию и гибкость.

0 голосов
/ 24 апреля 2011

Это зависит от того, что вам нужно делать со свойствами.Если свойства представляют только косвенный интерес, то 4 является очень гибким и компактным решением.Что я имею в виду под косвенным интересом?Если вам нужно получить и отобразить информацию в свойствах, это косвенно.Если вам нужно сделать расчеты или подробные манипуляции со свойствами, то это более прямо.Другими словами, если единственный метод, который вы, вероятно, будете использовать в свойствах, это ".ToString ()", тогда вы можете обойтись без 4. Эта схема обладает значительным преимуществом, позволяя вам добавлять новые типы свойств без изменения базы данных.схема, поскольку это просто новые вставки строк в таблицу типов свойств.

Если, с другой стороны, необходимо манипулировать различными типами свойств способами, которые зависят от их типов данных, то это будет проблемойхранить различные типы свойств в одном поле.Если это так, вы могли бы сделать 3., но это также проблема, потому что это требует, чтобы вы знали, к какой таблице перейти, чтобы получить значение определенного типа.Это не непреодолимая проблема, но она не изящна.

Вместо 3. Вы можете попробовать своего рода гибридный подход, в котором ваша таблица свойств имеет несколько столбцов, по одному для каждого типа данных, и желательноеще один столбец - возможно, вычисляемый столбец - который действует как «ToString».Таким образом, ваше косвенное использование может перейти к простому, предсказуемому месту, и только ваши более вовлеченные приложения должны беспокоиться о том, к какому столбцу перейти для определенного типа свойства.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...