Хороший дизайн базы данных, переменное количество атрибутов

Я пытаюсь создать базу данных, содержащую список оборудования. Все оборудование будет иметь определенные общие атрибуты (например, производитель, модель #, серийный номер и т.д.), Тогда есть другие атрибуты, характерные для определенного оборудования (т.е. Модем будет иметь доступ #, тогда как солнечная панель будет иметь выходную мощность). Я не уверен, как представить эти изменяющиеся атрибуты с хорошими принципами проектирования баз данных, я пробовал искать в Интернете, но я не совсем уверен, что искать.

Я придумал следующие возможные решения и свои первые мысли о них:

У вас есть одна большая таблица со всеми возможными атрибутами и просто поставьте null там, где она неприменима. Очевидно, это имеет некоторые недостатки.
У вас есть отдельная таблица для каждого типа оборудования. Кажется, это может быть кошмар для использования, если я хочу распечатать список всего оборудования, как узнать, какие таблицы искать?
У вас есть таблица с общими атрибутами и другие таблицы для каждого типа оборудования, доступ к которому осуществляется с помощью внешнего ключа для хранения дополнительных атрибутов. Возможно, я мог бы сделать эту работу, но это было бы громоздким и просто не было бы очень хорошим решением.
Модель типа объекта-атрибута. Просто не похоже на то, что я хочу сделать.

У меня нет большого опыта работы с базами данных, поэтому я изучаю, поскольку я здесь, любые ссылки, связанные с этой проблемой, или "должны читать" статьи по дизайну базы данных, будут оценены. Спасибо!

EDIT: Во-первых, я узнал, что мне нужно Google "Наследование наследования", что может помочь кому-либо, у кого есть аналогичный вопрос. Чтобы решить эту проблему, я решил использовать гибрид №2 и №3. Это было довольно просто, хорошо работает и решает проблему добавления дополнительных типов оборудования без сложности EAV. Спасибо за все комментарии и предложения!

Ответ 1

Варианты 1, 2 и 3 разделяют один очень серьезный недостаток: вам нужно изменить схему базовой таблицы, когда кто-то мечтает о новом атрибуте. В случае варианта 1 проблема усугубляется возможностью введения нового типа оборудования. Насколько вы уверены, что набор атрибутов фиксирован на все время? Насколько вы счастливы, если хотите, чтобы вы были отключены или сказали клиенту, что нет, у вас не может быть нового атрибута?

Если вы, скорее всего, будете делать запросы с общими атрибутами, вы можете попробовать гибрид 3 и 4 с тире 2, брошенным в разбиение по типу атрибута, а не на тип оборудования, что кажется гораздо более изменчивым. Вариант 4, если я правильно понимаю, представляет собой вариант нормальной версии варианта 1, который решает все присущие ему проблемы (разреженность и хрупкость).

INVENTORY( id*, model, manufacturer, serial )
ATTRIBUTE( id*, name, type, description )
INVENTORY_FACT_STRING( inv_id*, attr_id*, value )
INVENTORY_FACT_NUMBER( inv_id*, attr_id*, value )
INVENTORY_FACT_LIST_STRING( inv_id*, attr_id*, ordinal*, value )

и др.

Ответ 2

Альтернативы 1, 2 и 3 изложены Мартином Фаулером в одной из его книг и на его веб-сайте.

Наследование одиночной таблицы (вариант 1)

Наследование бетонных таблиц (вариант 2, вид)

Наследование таблицы классов (опция 3)

Мое предпочтение - вариант 3. Каждый имеет свое место в общей схеме вещей.

EAV позволяет добавлять новые атрибуты "на лету" очень хорошо. Но когда приходит время превратить данные в полезную информацию, база данных EAV может стать кошмаром.

У меня есть более длинный ответ, который я выложу по запросу.

Ответ 3

Я думаю, что вы столкнулись с обычной нормализацией базы данных. Вам нужны такие таблицы, как:

Items -> Id, Name, Model, Brand Id
Brands -> Id, Name
Attribute Names -> id, name
Attribute Mappings -> Id, Names Id, Items Id, Attribute Description

Если есть несколько атрибутов, перечислите их в таблицах атрибутов и сопоставьте их с идентификатором продукта и т.д. Попытайтесь придумать третью нормализованную форму

Нормализация базы данных

Ответ 4

Это трудная задача для решения любой базы данных SQL. Для MySQL нет отличного ответа.

1) Работает, и вы можете добавить несколько видов для важных типов оборудования. Он уменьшает число соединений и позволяет запрашивать и индексы в каждом поле.

2) Вы можете использовать весь запрос union. PostgreSQL и Informix имеют наследование таблицы.

3) Это часто выбор реализации. Опять же, вы можете использовать представления для объединений.

4) PostgreSQL, Informix, Oracle, IBM DB2 и MS SQL Server поддерживают поддержку типов данных XML для реализации пар значений.

На более высоком уровне вы могли бы разработать метамодель оборудования в XML. Затем вы можете использовать эту модель для генерации SQL-запросов схемы и кода CRUD.