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

Question

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

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

Теперь, поскольку все они являются списками, я думал о полиморфном подходе, создавая родительскую таблицу LISTINGS и другую дочернюю таблицу для каждой из различных категорий (COMPUTERS, CARS, CAMERAS). Каждая дочерняя таблица будет иметь list_id, который будет ссылаться на таблицу LISTINGS. Таким образом, при получении списка он получит строку из списка 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 различных категорий, не будет ли это неэффективным?

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

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

Answer 1

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

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

EDIT

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

Категория - Я бы - Описание

CategoriesListingsXref - CategoryId - ListingId

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

Вот и все.

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

Это действительно полный и показывает вам более 1 способ сделать это с за и против. Удачи.

Answer 2

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

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