как эффективно хранить данные со многими категориями и многими свойствами?

Question

У нас есть большое количество данных во многих категориях со многими свойствами, например.

category 1: Book 

properties: BookID, BookName, BookType, BookAuthor, BookPrice 

category 2: Fruit 

properties: FruitID, FruitName, FruitShape, FruitColor, FruitPrice 

У нас есть много категорий, таких как книга и фрукты. Очевидно, мы можем создать для них множество таблиц (например, MySQL), а каждая категория - таблица. Но это должно будет создать слишком много таблиц, и мы должны написать много «адаптеров», чтобы унифицировать манипулирование данными.

Трудности:

1) Каждая категория имеет разные свойства, и это приводит к различной структуре данных.

2) Свойства каждой категории, возможно, придется изменить в любое время.

3) Трудно манипулировать данными, если каждая категория таблица (слишком много таблиц)

Как хранить такого рода данные?

Answer 1

Вы можете разделить базу данных на две части: таблицы определения и таблицы данных. В основном таблицы определения используются для интерпретации таблиц данных, в которых хранятся фактические данные (некоторые могли бы сказать, что таблицы определения более элегантны, если они представлены в XML).

Следующая основная идея.

Определение Таблицы:

TABLE class 
class_id (int) 
class_name (varchar) 

TABLE class_property 
property_id (int) 
class_id (int) 
property_name (varchar) 
property_type (varchar) 

Таблицы данных:

TABLE object 
object_id (int) 
class_id (varchar) 

TABLE object_property 
property_id (int) 
property_value (varchar) 

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

Только мои два цента, я надеюсь, что это может помочь.

С уважением.

Answer 2

Если ваш сбор данных не слишком большой, модель Entity-Attribute-Value (EAV) может поместиться красиво.

В двух словах, эта структура позволяет определение Категории, список [обязательный или необязательный] Атрибуты (ака свойства) субъекты в данной категории включают в себя и т.д., в виде набора таблиц известный как метаданные, логическая схема данных, если хотите. Экземпляры сущности хранятся в двух таблицах в виде заголовков и таблиц значений, в соответствии с которыми каждый атрибут хранится в одной записи [SQL] более поздней таблицы (также называемой «вертикальной» памятью: то, что раньше использовалось в традиционной модели СУБД из нескольких записей таблицы значений).

Этот формат очень практичен, в частности, для его гибкости: он позволяет как поздние, так и текущие изменения в логической схеме (добавление новых категорий, добавление/изменение атрибутов данной категории и т. Д.), а также неявная управляемая данными логическая схема базового каталога на уровне приложения. Основными недостатками этого формата являются [несколько] более сложные, абстрактные, реализация и, в основном, некоторые ограничения в отношении масштабирования и т. Д., Когда размер каталога увеличивается, скажем, в диапазоне миллионов + сущностей.

См. Модель EAV, описанную более подробно в this SO answer of mine.

Answer 3

Запущенный этим вопросом и другими подобными, я написал blog post о том, как обращаться с такими случаями, используя базу данных графа. Короче говоря, в базах данных графов нет проблемы «как заставить дерево/иерархию в таблицах», так как нет необходимости в ней: вы сохраняете свою древовидную структуру, как есть. Они не хороши во всем (например, для создания отчетов), но это случай, когда блестят базы данных графа.