Простой вопрос моделирования данных SQL

Question

Учитывая, что у меня есть таблица, содержащая информацию об автомобиле, и одна из этих частей информации - VehicleType (обычно 6-20 символов), по каким техническим причинам лучше создавать таблицы следующим образом:

Транспорт

VehicleID
VehicleTypeID (INT) (относится к INT в таблице VehicleTypes)

против этого:

Транспортные средства

VehicleID
Тип транспортного средства (NVARCHAR (50))

Я могу думать о нескольких ...
1) Если описание Типа транспортного средства изменяется, оно должно быть изменено только в одной записи.
2) Требуется меньше места для хранения INT, чем NVARCHAR (в зависимости, конечно, от длины строки и особенно если я изменю на TINYINT.)

Несколько вопросов ...
1) Какие-либо соображения по поводу индексации? Я предполагаю, что если я собираюсь индексировать по типу VehicleType, он будет быстрее и займет меньше места, если я использую INT, а не NVARCHAR.
2) Есть вопросы оптимизации запросов? Я знаю, что первый метод требует JOIN, но я не ожидаю, что это облагается налогом на SQL 2008.

Я собираюсь защищать свою позицию и хочу получить как можно больше информации.

Спасибо, что нашли время ответить.

Спасибо
Darvis

Answer 1

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

Answer 2

Если описание Типа транспортного средства изменяется, оно должно быть изменено только в одной записи.

Правильно. А также насчет неиспользуемых в настоящее время «типов транспортных средств», например, автомобилей на топливных элементах.

Это " аномалии модификации данных "

Другие люди ответили на вопросы индекса ...

Answer 3

Первый - 3NF, правильно нормированные данные.

1) Какие-либо соображения по индексированию?

Индексы не создаются автоматически для внешних ключей. Создание индекса по внешнему ключу имеет смысл - его очень вероятно использовать в качестве критерия, но следует учитывать данные и доступ к нему. MySQL имеет ограничение на количество места для выделения индексов (другие не делают этого, о чем я знаю), и хотя индексы помогают получать данные, они также влияют на операторы INSERT / UPDATE / DELETE. Если вы работаете с SQL Server, я настоятельно рекомендую прочесть серию Ким Триппа «Переломный момент» .

2) Есть вопросы по оптимизации запросов? Я знаю, что первый метод требует JOIN, но я не ожидаю, что это облагается налогом на SQL 2008.

Объединение является наиболее предпочтительным средством поиска и обработки данных, а не подзапросом ...

Answer 4

помните, что nvarchar требуется 2 байта на символ, поэтому, если int равен 4 символам, для использования того же пробела вы можете использовать только 2 символа в столбце nvarchar.

Я бы пошел с int или даже smallint (до 32 767 и 2 байта памяти), если tinyint (до 255) недостаточно

Так что я бы использовал первую таблицу в этом случае

не знаю, как будут выглядеть ваши запросы, но может быть идея переключить столбцы и начать с typeid

Answer 5

Будьте осторожны, меняя имена в списках (домены), таких как Vehicle Type.

Если вы используете внешний ключ , то это повлияет на все существующие записи для этого типа - будет ли это допустимо?

Я не знаю, что такое Vehicle Type, но если Vehicle Type = Vehicle, Make проблемы могут возникнуть, если, например, Datsun меняет свое имя на Nissan - существующие в таблице транспортные средства по-прежнему Datsuns .....

Answer 6

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

Надеюсь, это поможет.