#database-design #foreign-keys
#проектирование базы данных #внешние ключи
Вопрос:
У меня есть требование разработать 2 или более таблиц. 1. Таблица подразделов 2. Таблица основных частей.
Одна основная часть может иметь несколько подразделов. Я подумываю о том, чтобы сделать что-то вроде
Таблица подразделов: идентификатор и имя
Таблица основной части: идентификатор и имя
Таблица отношений SubPart_MainPart: MainPart_ID SubPart_Ids (массив или разделенный запятой)
Есть ли способ поместить несколько subpart_id в один столбец в таблице отношений? или я должен использовать MainPart_D и SUbPart_ID в качестве объединенного первичного ключа в идентификаторе связи?
второй подход увеличит количество записей в таблице отношений. где в качестве первого подхода увеличится цикличность кода при попытке выполнить итерацию столбца, разделенного запятыми (SubPart_Ids).
Есть ли у вас какой-либо другой подход к этому?
спасибо за вашу помощь
Ответ №1:
Имеет ли подраздел одну или несколько основных частей?
Если только один основной компонент, то все, что вам нужно, это подраздел и таблица MainPart; идентификатор MainPart в таблице SubPart.
Если несколько основных компонентов, то вам нужна таблица SubPart_MainPart. Это не должен быть список, разделенный запятыми. Каждая строка должна быть одним связующим звеном между основной частью и подразделом.
Комментарии:
1. Все наоборот. В одной основной части можно использовать несколько подразделов. 2 основные части также могут использовать одну и ту же вспомогательную часть
2. Хорошо, поэтому используйте второй подход.
Ответ №2:
Первое правило дизайна базы данных: никогда ничего не храните в массиве или списке, разделенном запятыми. Вам нужна объединяемая таблица, которая имеет идентификатор основной части и идентификатор подраздела и по одной записи для каждой подраздела. Будет проще запрашивать и, вероятно, быстрее, если правильно проиндексировать.
Ответ №3:
Вам может понадобиться только две таблицы:
MainPartTable
*ID
Name
SubPartTable
*MainPartTable_ID
*SubPartTable_ID
Name
Ответ №4:
Наличие списка идентификаторов вложенных частей нарушало бы 1NF и крайне не рекомендуется практически при любых обстоятельствах. Если вы используете СУБД любого типа, то наличие большего количества строк в вашей таблице пересечений не является проблемой.
Еще одна вещь, о которой стоит подумать, — это почему у вас есть отдельная таблица подразделов. Обычный способ сделать что-то подобного рода (так называемая «спецификация материалов») — это иметь одну таблицу для деталей / сборок и одну таблицу, в которой указано «это вещи, из которых состоит эта вещь». Другими словами:
ASSEMBLY
- Assembly ID (PK)
- Assembly Name
COMPOSITION
- Contained In Assembly ID (PK, FK)
- Contains Assembly ID (PK, FK)
Редактировать: Также обратите внимание, что реальная спецификация материалов будет содержать поля в таблице СОСТАВА для количества и единицы измерения (количества).
Комментарии:
1. Итак, что вы предлагаете, это ASSEMBLY_ID NAME 1 Моторное масло 2 СОСТАВ цепи двигателя COMPONENT_ID ASSEMBLY_ID 1 1 2 1 3 1 4 1 2 2 4 2
2. Я не уверен, что цепочка и oil являются хорошим примером, поскольку одно не является частью другого. Я бы сказал, что часть вашей базы данных может выглядеть как СБОРКА: { 1 Двигатель; 2 Масло; 3 Цепь} и КОМПОЗИЦИЯ { 1 2; 13 1} Другими словами, двигатель содержит масло, а двигатель содержит цепь. Обратите внимание на приведенную выше правку, касающуюся количества и единиц измерения.