Хранение динамических полей в базе данных SQL

Question

У меня есть база данных 'product' для хранения информации о продукте. Для каждого продукта может быть дополнительно от 0 до 10 запасных частей, названия которых принимаются в динамической форме.

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

 __________________________________
|products                          |
|*********                         |
|id, name, address                 |
|__________________________________|
 __________________________________
|spareparts                        |
|*********                         |
|id, name                          |
|__________________________________|
 __________________________________
|products_spareparts               |
|*********                         |
|id, product_id, sparepartid       |
|__________________________________|

Таким образом, моя идея состоит в том, чтобы в таблице «запасных частей» было 10 строк, поскольку для продукта будет не более 10 запасных частей. Каждая строка будет иметь идентификатор и поле имени, в котором будут храниться имена, принятые из формы.

При создании товара, если есть запасная часть, для каждой запасной части ее имя будет добавлено в таблицу запасных частей, product_id и sparepart_id будут содержать идентификатор продукта и запасной части соответственно.

Запасные части создаются для каждого отдельного продукта. Его название принимается из формы, и два продукта могут иметь или не иметь одинаковые запасные части.

Будет ли это работать? Есть ли лучшие способы реализовать это?

Answer 1

Реляционные базы данных позволяют легко ограничить отношения для отношений 0/1. Они не облегчают ограничение количества для произвольных чисел.

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

Я бы на самом деле справился с этим, подсчитав запасные части одним из двух способов. Если бы я просто придерживался традиционных конструкций базы данных, я бы добавил число запасных частей в products и использовал бы ограничение check для значения. Триггер будет использоваться для поддержания значения в актуальном состоянии.

Скорее всего, я бы обернул все операции DML в хранимые процедуры и сделал бы там проверку. Для этого необходимо, чтобы все операции DML обрабатывались с помощью хранимых процедур.

«Необоснованным» способом является создание списка идентификаторов в виде отдельных столбцов - spareparts1, spareparts2 и т. Д. Это позволяет вам поддерживать отношения внешнего ключа и ограничивать число. Однако это усложняет последующие запросы на запасные части.

Answer 2

 __________________________________
|products                          |
|*********                         |
|id, name, address                 |
|__________________________________|
 __________________________________
|spareparts                        |
|*********                         |
|id, name, productid               |
|__________________________________|

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