2016-05-25 9 views
2

Мне интересно, какие наилучшие решения хранить отношения между двумя таблицами в mysql.Сохранение присвоений между двумя таблицами в MySQL

я следующая структура

Table: categories 

id | name   | etc... 
_______________________________ 
1 | Graphic cards | ... 
2 | Processors  | ... 
3 | Hard Drives | ... 

Table: properties_of_categories 

id | name  
_____________________ 
1 | Capacity 
2 | GPU Speed 
3 | Memory size 
4 | Clock rate 
5 | Cache 

Теперь мне нужно их иметь связи, и вопрос в том, что это лучше, эффективнее и легче решение, что очень важно, потому что могут быть сотни категорий и тысячи присвоенные им свойства.

Должен ли я просто создать еще одну таблицу со структурой, как

categoryId | propertyId 

или, возможно, добавить еще один столбец таблицы категории и хранить свойства в текстовом поле, как 1,7,19,23

Или, может быть, создать JSON файлы с именем, например, 7.json с содержанием как

{1,7,19,23} 

ответ

1

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

Вы можете структурировать таблицу, как так:

CREATE TABLE categories_properties_match(
    categoryId INTEGER NOT NULL, 
    propertyId INTEGER NOT NULL, 
    PRIMARY KEY(categoryId, propertyId), 
    FOREIGN KEY(categoryId) REFERENCES categories(id) ON UPDATE CASCADE ON DELETE CASCADE, 
    FOREIGN KEY(propertyId) REFERENCES properties_of_categories(id) ON UPDATE CASCADE ON DELETE CASCADE 
); 

Первичный ключ гарантирует, что не будет никаких дубликатов записей, это означает, что записи, которые соответствуют одной категории для одного и того же свойства дважды

+1

Wow Я только что узнал что-то новое. Я не знал о CASCADE. Спасибо за помощь. Я воспользуюсь вашим решением. –

2

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

Вы также можете использовать столбец JSON для хранения многих значений в одной из таблиц.

JSON Datatype представлен в MYSQL 5.7 и поставляется с различными функциями для извлечения и обновления данных JSON. Однако, если вы используете более старую версию, вам нужно будет управлять ею со строковым столбцом с некоторыми громоздкими запросами для манипулирования строками.

2

Требуемая структура зависит от типа отношения: один-ко-многим, много-к-одному или много-ко-многим (M2M).

Для одного-ко-многим внешний ключ (FK) на стороне «многих» связывает многие элементы с «одной» стороной. Обратное верно для многих-к-одному.

Для многих-ко-многим (M2M) вам нужна промежуточная реляционная (или соединительная) таблица точно так же, как вы предлагаете. Это позволяет вам «повторно использовать» обе категории и свойства в любых комбинациях. Однако это немного больше SQL - требуется 2 JOIN.

Если вы ищете производительность, то использование FK для первичных ключей (PK) будет очень эффективным, а запросы довольно просты. Использование JSON, по-видимому, потребовало бы, чтобы вы анализировали PHP и строили «на лету» второй запрос, который бы умножал вашу работу по кодированию и тестирование, передачу данных, накладные расходы процессора и ограничение масштабируемости.

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

До тех пор, пока ваши ключи проиндексированы (какие PK-ы), ваш JOIN в эту реляционную таблицу будет очень быстрым и эффективным.

Если вы используете CONSTRAINT с вашими отношениями, они гарантируют вам целостность данных: вы не можете удалить категорию, к которой привязано свойство. Это хорошая функция в долгосрочной перспективе.

Сотни и тысячи записей - это крошечное количество для MySQL. Вы использовали бы эту технику даже с миллионами записей. Так что не беспокойтесь о размере.

Базы данных RDBMS предназначены специально для этого, поэтому я бы рекомендовал использовать собственные функции, кроме как попробовать сделать это самостоятельно в JSON. (если мне не хватает какой-то новой функции JSON MySQL!)

* После публикации этого сообщения я действительно наткнулся на a new JSON MySQL feature. Кажется, из быстрого чтения вы можете реализовать всевозможные новые структуры и отношения, используя JSON и виртуальные ключи столбцов, возможно, устраняя необходимость в таблицах соединений. Это, вероятно, приведет к размыванию линии между MySQL как RDBMS и NoSQL.

+0

Ничего себе, это был исчерпывающий ответ. Спасибо. –

+0

Добро пожаловать. Ответ на dimlucas прав, я просто сказал вам больше «почему», это правильный выбор. Я был бы осторожен с каскадным удалением! Они работают, но вам, как правило, нужна логика приложения, чтобы гарантировать, что удаление - это то, что вы хотите. – scipilot

Смежные вопросы