Дизайн базы данных

Question

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

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

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

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

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

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

PartsApplicability
-------
ID
PartID
DeviceID

Devices
------
ID
Name

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

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

Answer 1

Я согласен с ответом Рекса М, это стандартный подход. Единственное, что вы можете сделать в таблице PartsApplicability, это удалить столбец ID и сделать PartID / DeviceID составным первичным ключом. Это гарантирует, что ваша Партия не может быть связана с одним и тем же устройством более одного раза, и наоборот.

Answer 2

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

Answer 3

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

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

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

Похоже, вы на пути к обнаружению нормальных форм базы данных .Третья нормальная форма или BNF должна быть хорошей целью, хотя иногда полезно нарушать правила.

Answer 4

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

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