Что не так с этой структурой данных?

Question

Мне было предложено описать, что не так с этой структурой данных, и как я ее улучшу.

Вот структура данных:

Вот то, что я до сих пор:

цена

• Автомобиль устанавливается только, если автомобиль находится в салоне, было бы более целесообразно поставить цену на автомобиль в таблице автомобилей

• Нет смысла хранить данные NULL в таблице автомобилей, было бы bet тер иметь компоновку, подобную этой:

  

• Там должно быть количество товарной позиции, чтобы показать, сколько из этого конкретного автомобиля в салоне, как некоторые автосалоны имеют несколько одинаковых автомобилей

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

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

Answer 1

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

Таким образом, вы должны разделить, что вверх, что-то вроде:

Делает: колонны makename, makecode

Модель: столбцы makecode (внешний ключ для марок), ModelName, modelcode

А теперь стол демонстрационного зала будет относиться только к моделям, поэтому он не может ссылаться на make по ошибке.

Поскольку у одной модели может быть много связанных с ней рядов табличек, вы не можете объединить эти два стола, чтобы они не разделялись и не отходили оттуда.

Answer 2

Вы правы, что повторяющиеся данные являются verboten.

Я бы сменил «выставочный зал» на «модель», потому что могут быть различные подкатегории моделей. IE Golf TDI против GTI и т. Д. ... и базовая цена (MSRP) будет применима к модели. Показать статус номера не имеет смысла для ценообразования - есть много, которые рекламируются, но не в выставочном зале или на лоте.

Я не думаю, что есть проблема с наличием столбца NULLable, если это то, что поддерживают данные. Либо все в порядке, и вы можете ориентироваться, как только у вас есть приличный объем данных, чтобы увидеть, что вам больше всего подходит. Но оптимизируйте после, а не раньше.

Answer 3

Похоже, что в структуре автомобилей хранятся автомобили и модели автомобилей. Это должно по крайней мере вызвать некоторые тревоги. У автомобилей, таких как Ford, VW и Peugeot, есть свои MakeCode. Модели автомобилей, такие как Fiesta и Golf, имеют свои ModelCode.

В оригинальной конструкции, модели автомобилей относятся к их маркам через ParentCarId и дублировать их MakeCode. Автомобильные марки не являются конкретными моделями и имеют нулевые значения для их ModelCode и ParentCarId.

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

Было бы разумно разбить эту таблицу на две части: одну для моделей и одну для моделей. Делает ID, Name и MakeCode. Модели имели бы ID, a Name, a ModelCode и MakeId (внешний ключ ID of Make).