Database Design

Question

Это общий вопрос базы данных, не связанный с какой-либо конкретной базой данных или языком программирования.

Я уже делал некоторые работы с базой данных, но обычно это работает. На этот раз я хочу планировать будущее.

У меня есть одна таблица, в которой хранится список запасных частей. Имя, номер детали, местоположение и т. Д. Мне также необходимо сохранить, какое устройство (и) оно применимо.

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

Моя идея - создать отдельную таблицу применимости. Он сохранит идентификатор детали и идентификатор устройства, если часть применима к нескольким устройствам, у нее будет более одной строки.

Parts 
------- 
ID 
Name 
Description 
Etc... 

PartsApplicability 
------- 
ID 
PartID 
DeviceID 

Devices 
------ 
ID 
Name 

Моих вопросы, будет ли это правильный способ сделать это, будет ли это обеспечить преимущество по сравнению с оригинальным способом, и есть ли лучший способ сделать это?

Спасибо за любые ответы.

Answer 1

Я согласен с ответом Rex M, это стандартный подход. Одна вещь, которую вы можете сделать в таблице PartsApplicability, - удалить столбец идентификатора и сделать PartID/DeviceID составным первичным ключом. Это гарантирует, что ваша часть не может быть связана с одним и тем же устройством более одного раза и наоборот.

Answer 2

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

Answer 3

Использование отдельной таблицы для хранения отношений «многие ко многим» - это правильный путь.

Некоторые из преимуществ для объединения таблиц являются

1. Части могут быть применимы к любому устройству и создания новых устройств или их частей не приведет к изменениям в схеме базы данных
2. Вам не нужно, чтобы сохранить обнуляет или другие sentinental значения для каждого отображения часть-устройство, которое не существует т.е. все будет чище
3. Ваши таблицы остаются узкими, что делает их легче понять

Вы, кажется, на своем пути, чтобы обнаружить database normal forms. Третья нормальная форма или BNF должны быть хорошей целью, хотя иногда бывает хорошей идеей нарушать правила.

Answer 4

Ваш второй дизайн - очень хороший дизайн и аналогичен тому, что я сделал (на работе и в моих собственных проектах) много раз с точки зрения описания отношений между вещами. Таблицы Lookup и их эквиваленты часто намного проще использовать, чем пытаться заполнить все в одной таблице.

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