Одиночное наследование или полиморфное?

Question

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

На сайте представлено множество категорий (например.Автомобили, Компьютеры, Камеры) и каждая категория объявлений имеет свои отдельные поля.Например, у автомобилей есть такие атрибуты, как количество дверей, марка, модель и мощность, а у компьютеров есть такие атрибуты, как ЦП, ОЗУ, модель материнской платы и т. д.

Поскольку все они представляют собой списки, я подумал о полиморфном подходе, создав родительскую таблицу LISTINGS и другую дочернюю таблицу для каждой из разных категорий (КОМПЬЮТЕРЫ, МАШИНЫ, КАМЕРЫ).Каждая дочерняя таблица будет иметь listing_id, который будет ссылаться на LISTINGS TABLE.Таким образом, когда извлекается список, он извлекает строку из LISTINGS, к которой присоединена связанная строка в связанной дочерней таблице.

LISTINGS
-listing_id
-user_id
-email_address
-date_created
-description

CARS
-car_id
-listing_id
-make
-model
-num_doors
-horsepower

COMPUTERS
-computer_id
-listing_id
-cpu
-ram
-motherboard_model

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

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

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

Как бы это сделали такие сайты, как Kijiji?

Answer 1

Дизайн вашей базы данных в порядке.Нет причин менять то, что у вас есть.Я видел, как поиск осуществлялся несколькими способами.Один из них заключается в том, чтобы ваша хранимая процедура поиска объединяла все таблицы, в которых вам нужно выполнить поиск, и индексировала столбцы, по которым осуществляется поиск.Второй способ, который я видел, работал довольно хорошо, заключался в том, чтобы иметь таблицу, которая используется только для поиска и получает копии любых полей, по которым необходимо выполнить поиск.Затем вы поместите триггеры в эти поля и обновите таблицу поиска.

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

РЕДАКТИРОВАТЬ

Вам понадобятся следующие таблицы.

Категории - ID - Описание

CategoriorySlistingsxref - CategoryId - ListingId

С помощью этой модели перекрестных ссылок вы можете объединить все свои объявления по определенной категории во время поиска.Затем добавьте немного динамического SQL (потому что его легче понять) и создайте свой запрос, включив в него поля, по которым вы хотите выполнить поиск, и вызовите выполнение по вашему запросу.

Вот и все.

РЕДАКТИРОВАТЬ 2 Это, кажется, немного больше дискуссии, которое мы можем окупить в этих коробках для комментариев.Но все, что мы обсудим, можно понять, прочитав следующий пост. http://www.sommarskog.se/dyn-search-2008.html

Он действительно полный и показывает вам более одного способа сделать это с плюсами и минусами.Удачи.

Answer 2

Я думаю, что выбранный вами дизайн подойдет для только что описанного вами сценария.Хотя я не уверен, должны ли таблицы подклассов иметь собственный идентификатор.Поскольку CAR является листингом, имеет смысл, чтобы значения были из одного и того же «домена».

На типичном сайте тематических объявлений данные для объявления записываются один раз, а затем доступны только для чтения.Вы можете воспользоваться этим и сохранить данные во втором наборе таблиц, которые более оптимизированы для поиска именно так, как вы хотите, чтобы пользователи искали.Кроме того, проблема поиска действительно существует только для «общего» поиска.Как только пользователь выберет определенный тип объявления, вы можете переключиться на таблицы подклассов, чтобы выполнить более расширенный поиск (ОЗУ > 4 ГБ, процессор = перегружен).