Супер общая структура базы данных

Question

Скажем, у меня есть магазин, в котором продаются продукты, которые подпадают под различные категории ... и каждая категория имеет связанные свойства ... например, сверло может иметь покрытие, диаметр, угол спирали или что-то еще.Проблема в том, что я хотел бы, чтобы пользователь мог редактировать эти свойства.Если бы я не был заинтересован в том, чтобы пользователь изменил свойства, и я строил хранилище для определенного набора категорий, у меня была бы одна таблица для сверл и т. Д. В качестве альтернативы я мог бы просто изменить схему в Интернете, но этокажется, это делается не очень часто (если только мы не говорим о phpmyadmin или о чем-то подобном), и плюс, что совсем не вписывается в то, как модели связаны с таблицами.

В общем, яЯ заинтересован в реализации структуры базы данных с несколькими таблицами с различными типами данных (поскольку диаметр может быть десятичным, покрытие будет строкой / индексом в таблице и т. д.) в рамках mysql.Есть идеи, как это можно сделать?

Answer 1

Если вы используете новейшую версию mysql (5.1.5 или выше), вы можете сохранить свои данные в виде XML в базе данных.Затем вы можете запросить эти данные, используя вот такие вот теги.

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

SELECT SUM( EXTRACTVALUE( infoxml, '/info/widget_count/text()' ) ) as widget_count 
  WHERE product_type="widgetpack"

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

Answer 2

Сначала создайте Свойство . Это будет содержать все свойства. Он должен иметь (как минимум) столбец «Имя» и столбец «Тип» («строка», «логическое значение», «десятичное число» и т. Д.). Примечание: первичные ключи подразумеваются для всех этих таблиц.

Далее создайте таблицу CategoryProperty . Здесь вы сможете назначить свойства для категории. Он должен иметь следующие столбцы: CategoryID, PropertyID. Оба внешних ключа.

Затем создайте таблицу Category . Это описывает категории. Он должен иметь столбец Имя и, возможно, некоторые другие столбцы, такие как Описание.

Затем создайте таблицу ProductCategory . Здесь вы будете назначать категории для каждого продукта. Он должен иметь следующие столбцы: CategoryID, ProductID. Оба внешних ключа.

Затем создайте таблицу PropertyValue . Здесь вы «создадите экземпляр» свойств и дадите им значения. Столбцы включают ProductID, PropertyID и PropertyValue. Первичный ключ может состоять из ProductID и PropertyID.

Наконец, создайте таблицу Product , которая просто описывает каждый продукт со столбцами, такими как Имя, Цена и т. Д.

Обратите внимание, что для каждого отношения есть отдельная таблица. Если вам нужна только одна категория для каждого продукта, вы можете отказаться от таблицы ProductCategory и просто поместить поле CategoryID в таблицу Product. Аналогично, если вы хотите, чтобы каждое свойство принадлежало только одной категории, вы можете поместить столбец PropertyID в таблицу Category и избавиться от таблицы CategoryProperty.

Наконец, вы не сможете проверить тип данных для каждого свойства, поскольку каждое свойство имеет свой тип (и это строки, а не столбцы). Поэтому просто сделайте столбец PropertyValue строкой и затем выполните проверку в качестве триггера или в своем приложении, проверив столбец Тип таблицы свойств для этого свойства.

Answer 3

Просто используйте базу данных. Он уже все это делает. Бесплатно. И быстро. Как таблица продуктов указывает на таблицу свойств с типами данных, которые отличаются от таблицы со столбцами? Это не. Сохраните, если вы используете таблицы БД, которые вы получаете, чтобы использовать SQL для запроса его во всех видах аккуратных и эффективных способов по сравнению с вашими (кросс-таблицы сосут в базе данных SQL).

Получить новый продукт, создать новый стол. Ничего страшного. Получить новое свойство, изменить таблицу. Если в этой таблице 1M продуктов, да, это может быть медленное обновление (зависит от БД). У вас есть продукты 1M? Я не думаю, что WalMart имеет 1M продуктов.

Создание баз данных поверх баз данных - глупость. Просто используйте тот, который есть. Это замазка в ваших руках. Сделай это по своей прихоти.

Answer 4

Если я правильно понимаю, что вы спрашиваете, то, по общему признанию, хакерское решение было бы иметь таблицу products, которая имеет отношение к связанным таблицам, product_properties и product_properties_lookup (или как-то лучше) где product_properties_lookup имеет запись для каждого возможного свойства, которое может иметь product, и где product_properties содержит значение свойства в виде строки с идентификатором свойства и идентификатором продукта. Затем вы можете привести значение свойства в любой тип, который вы хотите. Не идеально, но я не уверен, что еще нужно сделать, кроме добавления отдельных столбцов в БД для типов свойств.

Answer 5

Возможно рассмотрим подход Entity-Attribute-Value (EAV) (конечно, не для всей модели!)

Похожие вопросы

• База данных значений атрибутов сущностей и строгая реляционная модель Вопрос электронной коммерции
• Подход к общей структуре базы данных
• Как построить расширяемую модель данных

Answer 6

Посмотрите на эту схему базы данных на DatabaseAnswers.org :

http://www.databaseanswers.org/data_models/products_and_generic_characteristics/index.htm