Какой из вариантов схемы базы данных лучше?

Question

[Марк]

У меня есть следующие сущности:
- документ, целью которого есть просто групировка связанных грузов (например, они все принадлежат одному клиенту);
- грузы;
- документ о перемещении груза.
На данный момент схема устроена таким образом, что каждый груз имеет свои собственные атрибуты.

Необходимо реализовать нововведение, которое приведет к уменьшению дублирования данных, которое происходит в результате того, что в пределах одного группирующего документа существуют почти идентичные грузы (с одинаковыми габаритами и весами), которые отличаются только ID.
Пока что есть 2 варианта реализации. Первый – разделить таблицу грузов так, что в одной таблице будут храниться атрибуты груза (габариты и вес), а в другой – экземпляры грузов.

Второй – ввести дополнительную колонку "Количество" прямиком в таблицу грузов, но тогда придется добавить колонку "Порядоковый номер груза" в таблицу "Документ о перемещении", чтобы знать какой именно груз записан в документ.

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

Comments

[Vitsliputsli]

разделить таблицу грузов так, что в одной таблице будут храниться атрибуты груза (габариты и вес), а в другой – экземпляры грузов

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

[DevMan]

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

[Василий Банников]

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

А это действительно нужно дедуплицировать?
Есть договор на перевозку, в рамках него перечисляются машино-места, каждое машино-место имеет определённые характеристики (размер и массу)

Характеристики машиноместа не являются самостоятельной сущностью.
Ты же не пытаешься дедуплицировать людей, если они являются полными тёзками?

[Марк]

Vitsliputsli, да, именно так я и планировал сделать, если следовать первому варианту.

[Марк]

DevMan, это я и имел ввиду, когда писал о лишнем JOIN.

[Марк]

Василий Банников, ну так-то ты прав. Но я попытался найти такие решения, чтобы не потерять связь того, какое машино-место какой сущности в БД соответствует.

[Василий Банников]

Марк, а с какой сущностью машиноместо сопоставляется?

Если это товары, то несколько разных товаров (или несколько единиц одного) вполне могут идти как одно машиноместо и при этом одна единица одного товара вполне может разделиться на два машиноместа.

[Марк]

Василий Банников, машиноместо сопоставляется с грузом, каждый груз — отдельное машиноместо. Если у меня несколько единиц одного товара, но они находятся внутри 1 коробки, то это 1 машиноместо, если товары не соединены физически (не обмотаны скотчем, не находятся внутри одного мешка или коробки), то это разные места. Даже если у меня 5 идентичных коробок, что их невооруженным взглядом не различишь, но физически они никак между собой не скреплены, то каждая коробка считается отдельным местом.

Answer 1

[MVV]

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

Comments

[Марк]

Да, получается, что массогабаритные харастеристики груза отдельной сущностью не являются и, скорее всего, правильно было бы оставить все так как и есть. Единственной причиной почему я хотел добавить колонку "Количество" в таблицу "Груз" было уменьшение дублирования данных, так как на самом деле груз обладает большим количеством атрибутов (а не только массой и габаритами). Возможно, я не правильно освоил теорию проектирования баз данных, поэтому меня клонит к таким решениям.
Каждый отдельный груз, даже с одинаковыми массогабаритными характеристивами в моем случае все-таки является отдельной сущностью, поэтому мне нужно иметь возможность отслеживать каждый груз, именно поэтому во втором варианте я добавил колонку "Порядковый номер груза" в таблицу "Документы о перемещении".
Выходит, что тогда мне, скорее всего, нужно оставить все как есть и не пытаться придумать что-то с этим количеством однотипных грузов.