Одна большая таблица или отдельные таблицы для хранения обзоров продуктов по типам деталей?

Question

Мне нужно сделать 100 или около того таблиц. У меня есть таблицы с именем PartStatsXXX, и все создаваемые таблицы будут называться PartReviewXXX (они соединяются друг с другом в отношении 1: n).

Эффективно ли создавать одну большую таблицу для хранения всех отзывов о товаре (товар и деталь одного термина с точки зрения бизнеса)? Кто-то упомянул создание связи между PartStatsXXX и PartsReview (одна большая таблица) со значением XXX как части первичного ключа от PartStatsXXX.

XXX - это название типа детали (например, аккумулятор, жгут проводов и т. Д.). Так что это будет varchar. Должен ли я сделать составной ключ? Тип детали не изменяет имена (хотя некоторые имена деталей могут иметь несколько имен в зависимости от культуры), но на самом деле это не идентификатор кандидата. Затем было упомянуто, что я могу получить несколько представлений о том, что мне нужно, в зависимости от значения XXX.

Надеюсь, это имеет смысл. Какой будет лучший подход?

Спасибо

Answer 1

Многостоловый PartStatsXXX - плохая идея: трудно правильно написать код или использовать фреймворк, сложно поддерживать, кошмарно запрашивать ...

Используйте две таблицы: PartStats и PartsReview с соответствующими ключами и индексами для повышения производительности.

Answer 2

Более эффективно создавать таблицы на основе того, что вы хотите хранить в каждой из них. Вам не нужно 100 столов для 100 продуктов. Вам нужна 1 таблица для всех продуктов.

Так что для ваших нужд я бы создал 2 таблицы:

products
========
id INT
name VARCHAR 

product_reviews
===============
id INT
product_id INT (foreign key to products.id)
rating INT (example column)

Answer 3

Если вы не храните разные типы данных для обзоров каждого продукта (т. Е. Каждая таблица имеет свой набор столбцов), использование другой таблицы для каждого продукта создаст ненужный кошмар.

Как правило, вам никогда не нужно иметь более одной таблицы с одинаковым набором столбцов. Как уже предлагалось, одна таблица со столбцом product_id - это путь.

Answer 4

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

1) Разработка и реализация реляционной базы данных Pro SQL Server 2008 (c) Луи Дэвидсон
2) Реляционная база данных четко объясняет (с) Ян Харрингтон

Удачи!

Answer 5

Если вы хотите быстро и грязно избавить себя от боли, используйте две таблицы.

CREATE TABLE PartStats (
  ...,
  PartType VARCHAR(255),
  ...
);

CreateTable PartReview (
  ...
  PartType VARCHAR(255),
  ...
);

и затем присоединитесь к ним через

SELECT ...
FROM PartStats ps JOIN PartReview pr
  ON ps.PartType = pr.PartType;

Это избавляет вас от сотен таблиц, но настраивает вас на другую проблему: избыточные данные (PartType), которые могут быть не синхронизированы. Опечатка в PartType может привести к появлению осиротевшего отзыва.

Решение, предполагающее, что вы можете иметь более одной записи PartStats для данного PartType, состоит в добавлении третьей таблицы к единственному старшему из имен PartType.

CREATE TABLE PartType (
  ID INT ...,
  PartType VARCHAR(255),
  PRIMARY KEY (ID)
);

и организуйте для PartStats и PartReview использование идентификатора PartType. Например,

CREATE TABLE PartStats (
  ...,
  PartType_ID INT REFERENCES PartType(ID),
  ...
);

CREATE TABLE PartReviews (
  ...
  PartType_ID INT REFERENCES PartType(ID),
  ...
);

Это предотвратит создание PartStats или PartReview для несуществующего PartType.

Если производительность запросов становится проблемой, добавление вторичных индексов для PartType_ID поможет.