СУБД 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? Тут и наследование не нужно, и добавление новых типов машин без добавления таблиц выходит.

Кот Матроскинuser7320Да, я об этом и подумал. Теперь у меня так, как ниже. Кто что скажет?

Я это с самого начала и посоветовал. В этой новой схеме что Вам мешает сделать PK в Car, а внешние ключи в дочерних таблицах?
А можно эти внешние ключи в дочерных таблицах сделать первичными ключами в этих дочерних и одновременно идентификаторами? Чтобы не заводить отдельный столбец для FK в каждой дочерней таблице. Т. е. получится, что Car.Id будет совпадать с соответствующим SportCar.Id. Т. е. примерно так:

Car
IdPriceCarType9991 000 000SportCar1001500 000FamilyCar

SportCar
IdMaxSpeed999300 км/ч

FamilyCar
IdFuelRate10011л/10км

Или какие-то подвохи могут быть?



Вообще, меня удивляет, что нет какого-то стандартного решения на такую задачу. По идее, такая задача - у каждого первого магазина или склада товаров. Почему ворох решений без явного варианта-лидера?

авторА можно эти внешние ключи в дочерных таблицах сделать первичными ключами в этих дочерних и одновременно идентификаторами? Чтобы не заводить отдельный столбец для FK в каждой дочерней таблице. Т. е. получится, что Car.Id будет совпадать с соответствующим SportCar.Id. Т. е. примерно так:
Ну и получается, что стоит сделать ещё один шажок и решение вырождается в то, что Dimitry Sibiryakov предложил - всё в одной таблице. Ну, плюс ссылка на таблицу CarType.

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

У Mr.Fontaine , вроде, в редакторе меньше логики, но более сложные (и долгие) запросы к БД. Тот же плюс, что и у Dimitry Sibiryakov - не надо городить новых таблиц при появлении нового типа машин. И нету минуса при появлении новых параметров - т. е. не надо вставлять новые столбцы в таблицы, а обойтись всего лишь новыми записями.

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

Dimitry Sibiryakovuser7320По идее, такая задача - у каждого первого магазина или склада товаров

Нет, ни у магазинов, ни тем более у склада такой задачи нет. С теми задачами, которые у
них есть справляется EAV.

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

Может ли считаться в этой модели минусом то, что придётся добавлять столбцы при добавлении типа машин или параметров машин? В варианте Mr.Fontaine, например, столбцов добавлять не надо. Что вы про его вариант думаете, кстати?

Dimitry Sibiryakovuser7320Я прочитал в статье в Википедии про EAV про разрежённую матрицу - вы, по
сути, это и предлагаете.
Да, я предлагаю разреженную матрицу, поскольку с EAV ты не справишься - там нужны
определённым образом заточенные мозг и руки.

Ну а что вы всё же скажете про вариант Mr.Fontaine ?

Mr.FontaineВ общем достаточно таблиц
Машины(id, name, id_type)
Типы машин (id, name)
Параметры (id, name)
Список параметров по типам машин (id_type, id_parameter, is_main)
Характеристики машин (id_car, id_parameter, value)

Если так необходимо иметь парметиры разных типов, то сделай в таблице параметров поле type_value
А таблицу характиристик машин разбей на требуемое количество типов: Строковые характеристики машин, Числовые характеристики машин, Бинарные характеристики машин и т.д.
Я так понимаю, что у таблиц связей ("Список параметров по типам машин", "Характеристики машин") поле идентификатора не обязательно?

Всем спасибо, я понял как делать и составил схему БД.

авторКаскадные удаления - это вообще большой экстрим, который в реальной жизни встречается крайне редко. В норме ограничения выглядят как "не дать удалить родителя, если есть дети", "не дать вставить/обновить ребенка, если нет родителя".
И у Вас это можно сделать только триггерами.
Т. е. если я хочу удалить все продукты определённого типа, то вместо того, чтобы удалить тип продукта и каскадно автоматически удалить все продукты этого типа, я должен сначала удалить все продукты этого типа, а потом - этот тип? И сделать триггер, который не даст удалить тип продукта, пока есть хоть один продукт этого типа? Так правильно?

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


Это Eav, тоже можно, но простое наследование таблиц — более простой и прямой вариант.[/quot]
Я использовал и то, и другое. В частности, общие поля я вынес в родительскую таблицу, а частные - в потомковые. А EAV, я использовал для той сложной штуки, где надо было сделать отношения между типами машин, собственно машинами, параметрами и главными параметрами, да ещё с разным типом данных. Это упрощённый пример. На самом деле у меня задача немного посложнее, поэтому там нашлось место и наследованию, и EAV. Надеюсь, это не является плохой практикой - смешивать разные способы организации данных в одной БД?

Mr.FontaineВ общем достаточно таблиц
Машины(id, name, id_type)
Типы машин (id, name)
Параметры (id, name)
Список параметров по типам машин (id_type, id_parameter, is_main)
Характеристики машин (id_car, id_parameter, value)

Если так необходимо иметь парметиры разных типов, то сделай в таблице параметров поле type_value
А таблицу характиристик машин разбей на требуемое количество типов: Строковые характеристики машин, Числовые характеристики машин, Бинарные характеристики машин и т.д.
Я вот по последнему не понял, когда нужны разные типы параметров. Как лучше сделать? В таблице числовых характеристик завести столбцы типа stringValue, integerValue, floatValue и т. п. - "разрежённая матрица"? Или лучше на каждый тип значения свою таблицу? Или ещё как-то?

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

Ну, насчёт правил удаления это с опытом приходит. Где-то надо каскадно, где-то лучше наллы установить.