Структура базы данных для сайта объявлений

Question

Я занимаюсь разработкой сайта объявлений, аналогичного Quickr.com.

Основная проблема заключается в том, что для каждой категории требуется свой набор свойств.Например, для мобильного телефона атрибутами могут быть Производитель, Операционная система, Сенсорный экран, Включен ли 3G и т. Д. В то время как для квартиры указываются атрибуты Количество спален, Меблированный, Какой этаж, общая площадь и т. Д.Атрибуты и количество атрибутов варьируется для каждой категории, я храню атрибуты и их значения в отдельных таблицах.

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

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

Эта таблицахранит всю рекламу.Одна запись на объявление.

ad_id
ad_title
ad_desc
ad_created_on
cat_id

Пример данных

-----------------------------------------------------------------------------------------------
|ad_id | ad_title    | ad_desc                                       | ad_created_on | cat_id |
-----------------------------------------------------------------------------------------------
|1     | Nokia Phone | Nokia n97 phone for sale. Excellent condition | <timestamp>   | 2      |
-----------------------------------------------------------------------------------------------

Таблица adss_cat

В этой таблице хранятся все доступные категории.cat_id в таблице adss_ads относится к cat_id в этой таблице.

cat_id
категория
parent_cid

Пример данных

-------------------------------------------
|cat_id| category            | parent_cid |
-------------------------------------------
|1     | Electronics         | NULL       |
|2     | Mobile Phone        | 1          |
|3     | Apartments          | NULL       |
|4     | Apartments - Sale   | 3          |
-------------------------------------------

Таблица tables_attribute

Эта таблица содержит все доступные атрибуты для определенной категории.Относится к таблице adss_cat.

attr_id
cat_id
input_type
attr_label
attr_name

Пример данных

-----------------------------------------------------------
|attr_id | cat_id | attr_label       | attr_name          |
-----------------------------------------------------------
|1       | 2      | Operating System | Operating_System   |
|2       | 2      | Is Touch Screen  | Touch_Screen       |
|3       | 2      | Manufacturer     | Manufacturer       |
|4       | 3      | Bedrooms         | Bedrooms           |
|5       | 3      | Total Area       | Area               |
|6       | 3      | Posted By        | Posted_By          |
-----------------------------------------------------------

Таблица adss_attr_value

В этой таблице хранится значение атрибута для каждого объявления в таблице adss_ads.

attr_val_id attr_id ad_id attr_val

Пример данных

---------------------------------------------
|attr_val_id | attr_id | ad_id | attr_val   |
---------------------------------------------
|1           | 1       | 1     | Symbian OS |
|2           | 2       | 1     | 1          |
|3           | 3       | 1     | Nokia      |
---------------------------------------------

========

• Можно ли использовать этот дизайн?
• Можно ли индексироватьэти данные с помощью solr?
• Как выполнить фасетный поиск по этим данным?
• Поддерживает ли MySQL свертывание полей как solr?

Answer 1

Я предлагаю удалить cat_id из таблицы classifieds_attribute, а затем создать новую таблицу.

Новая таблица будет выглядеть так:

cat_attr | id | cat_id | attr_id

Это должно помочь вам уменьшить избыточность.

Answer 2

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

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

Это также определенно усложняет ваш поиск - что, по-моему, является одной из причин вашего вопроса.

Я бы предложил создать дополнительную таблицу, которая будет использоваться для управления иерархией категорий выше конечного уровня. Он будет выглядеть точно так же, как ваша таблица classifieds_cat, за исключением того, что инволютивное отношение будет очевидно к новой таблице Тогда classifieds_cat.parent_cid становится FK для новой таблицы, а не развернутым FK для classifieds_cat.

Я думаю, что это изменение схемы уменьшит сложность управления приложениями и данными.