СУБД MS SQL Server.

Есть машины. У каждой машины есть цена. Машины бывают разных видов и у каждого вида свой основной параметр - спортинвые (макс. скорость), грузовые (грузоподъёмность), семейные (расход горючего). У каждого основного параметра по условию будет свой тип данных. Как это сделать в БД и как отношения расставить?

Я придумал так, как на картинке во вложении. Проблема в том, что я сомневаюсь в правильности того, что один внешний ключ в таблице Car может сослаться на несколько первичных в разных таблицах. Также я не знаю, какие лучше правила обновления-удаления к таким отношениям приложить - каскадные, может, не стоит? Но по-другому лучше не могу придумать, как сделать. Посоветуйте, пожалуйста, какой лучше вариант организации таблиц для такой задачи сделать.

авторПроблема в том, что я сомневаюсь в правильности того, что один внешний ключ в таблице Car может сослаться на несколько первичных в разных таблицах.
Ну, т. е. дизайнер БД дать-то может мне и даст так сделать, но я сомневаюсь в правильном архитектурном решении.

Если для кого-то кажется это простым - наверное. Я давно уже не брал в руки шашек и последний год вообще к проектированию БД отношения не имел. Всё повылетало из головы.

Да, в таблице CarType перечислены все типы, которые представлены таблицами - для каждого типа по отдельной таблице.

Dimitry Sibiryakovuser7320Посоветуйте, пожалуйста, какой лучше вариант организации таблиц для такой
задачи сделать.
Одна таблица Car, вторая таблица - "Характеристики автомобиля", куда и спихать все
характеристики. Ссылается на первую.

Хмм, у меня пример не совсем удачный... Вобщем, ограничение, что не все характеристики одного типа автомобиля должны присутствовать в другом. Предлагаете при вставке нового автомобиля просто сделать пропуски в тех стобцах, для которых нет данных?

И да, мне ещё важно знать, имеет ли право на жизнь моё решение и какие у него могут быть минусы.

Ещё проблема в том, что надо будет выводить автомобили по типу и для каждого типа - только актуальные для этого типа данные. Т. е. нельзя, например, вывести прочерк в грузоподъёмности для спортивного автомобиля.

Кот Матроскинuser7320И да, мне ещё важно знать, имеет ли право на жизнь моё решение и какие у него могут быть минусы.
Правильнеее сделать наоборот - первичный ключ в таблице Car и внешние ключи в дочерних таблицах.
Почему? Количество машин с конкретной максимальной скоростью ограничено (скажем, есть градации максимальных скоростей, даже если эти градации идут с шаком 1 км/ч, например), а количество машин вообще - нет. На одну машину приходится один класс машин с конкретной максимальной скоростью, но на один класс машин с конкретной максимальной скоростью приходится много машин.

Dimitry Sibiryakovuser7320нельзя, например, вывести прочерк в грузоподъёмности для спортивного
автомобиля.
А что там можно вывести? Т.е. как ты такой вывод себе представляешь?

По вашему вывод будет примерно такой:

список машин для семьи:

№PriceMaxSpeedTonnageFuelRate1500 000--1л/10км

список спортивных машин:

№PriceMaxSpeedTonnageFuelRate11 000 000300 км/ч--

список машин вообще:

№PriceMaxSpeedTonnageFuelRate1500 000--1л/10км21 000 000300 км/ч--

Нелогично.

Dimitry Sibiryakov,

кроме того, при добавлении в базу нового типа автомобилей, для которых появляется новый ключевой параметр, которого раньше не было для других автомобилей (его может даже ПРИНЦИПИАЛЬНО не быть для других автомобилей), придётся редактировать схему уже созданной и заполненной таблицы "Характеристики автомобилей". Я вот не уверен, что это можно делать - может, придётся создавать новую таблицу и переносить в неё данные из старой.

А в моём случае просто добавляется свежая таблица в БД, добавляется запись в таблицу CarType и добавляются записи в таблицу Car - ничего не надо менять ИЗ УЖЕ ГОТОВОГО и ничего никуда переносить не надо.

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

Dimitry Sibiryakovuser7320По вашему вывод будет примерно такой:

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

В выводе должны быть только те данные, которые актуальны для конкретного типа автомобиля. Т. е. сущность "тип автомобиля" уже как минимум должна быть.

Вот похожую проблему нашёл http://www.sql.ru/forum/67152/nasledovanie-v-baze-dannyh . Но там так и не предложили конечной схемы БД, а топикстартер как-то и забыл про это, похоже.

Dimitry Sibiryakovuser7320В выводе должны быть только те данные, которые актуальны для конкретного
типа автомобиля.
Как это должно выглядеть ?

машины для семьи:

№PriceFuelRate1500 0001л/10км

грузовые машины:

№PriceTonnage11 500 0005т

и т. д.

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

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

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


Кот Матроскинuser7320пропущено...

Почему? Количество машин с конкретной максимальной скоростью ограничено (скажем, есть градации максимальных скоростей, даже если эти градации идут с шаком 1 км/ч, например), а количество машин вообще - нет. На одну машину приходится один класс машин с конкретной максимальной скоростью, но на один класс машин с конкретной максимальной скоростью приходится много машин.
у Вас SportCar и т.д. - это справочники, а не дочерние таблицы, что ли?
Тогда это все равно плохое решение
1. Ограничений целостности, считай, нет.
2. Cоединение делать сложно - потребуется динамический SQL.
Я так понимаю, что ограничения целостности можно организовать просто добавив каскадные правила для удаления и хорошо написав софт, работающий с БД?

SportCar и т.д. - это да, вроде как справочники. Но по идее надо наследованием, ибо если без, то придётся, скорее всего, вводить категории основного параметра (например, не любая макс. скорость, а "до 300 км/ч", "до 320 км/ч" и т. д.) и относить каждую машину к категории основного параметра, а не к его произвольному значению. Иначе будет тупо список уникальных значений основного параметра. Наследование позволит избежать категорий и сделать то, что по сути и требуется - список уникальных значений основного параметра. При этом общие для всех машин свойства (Price, например) выносятся в родитеслькую таблицу, а уникальные для каждого конкретного типа машин - в соответствующие таблицы типов машин.

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


авторя вот чё понять не могу.... Почему у каждого параметра будет свой тип данных?
Таковы требования.

авторСколько можно всем повторять?
Используйте наследование таблиц, оно же отношение подкатегории.
Да, я об этом и подумал. Теперь у меня так, как ниже. Кто что скажет?

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

авторМашины(id, name, id_type)
Типы машин (id, name)
Параметры (id, name)
Список параметров по типам машин (id_type, id_parameter, is_main)
Характеристики машин (id_car, id_parameter, value)
Я так понимаю, что при добавлении нового типа машин (и новых параметров) у вас новых таблиц добавлять не надо. Да, это лучше, чем мой вариант. Подумаю над этим.

MasterZiv, скажите, как вам пример Mr.Fontaine? Тут и наследование не нужно, и добавление новых типов машин без добавления таблиц выходит.