Кот Матроскин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 и т. п. - "разрежённая матрица"? Или лучше на каждый тип значения свою таблицу? Или ещё как-то?

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

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