Вы не могли бы выложить исходник? Весь день сижу над этим, плохо голова работает :) По поводу того, чтобы соединить, возможно вы и правы, но я намеренно их разделял, потому что достаточное количество полей будут пусты, так же как минимум один из типов будет иметь подпункты, скажем так. Даже не знаю, стоит ли оно того, что половина полей будут просто со значением null?
Ваш способ интересный. Только вот, тут не хватает присваивания идентификатора внутри самого типа. То есть параметры и их значения еще делятся на подгруппы, как-то так. То есть в каждом параметре огромное количество разных параметров + их значений, а пользователю нужно предоставить именно его параметр со значением.
Ihor Kalashnikov: Понимаю, просто хотел сохранить целостность БД, чтобы в случае какой-то ошибки или смене ID у родителя, менялся там, где должен. Смотрел массу примеров, в которых почти все в БД таблицы связаны, при этом открыл БД движков ДЛЕ и ВОРДПРЕСС, там вообще нет внешних ключей, не знаю почему.
Что касается вашего первого абзаца: ту модель, что вы нарисовали, я ее перерисовал более наглядно (думаю, что правильно), там как раз проблема в том, что при смене ID родителя должен меняться определенный ID в таблице "user_transport", но он просто не может меняться, потому что он не захватывает тот самый тип, если же писать запрос, то можно учесть, что с такими то ID типами поменять значения... Но это не на уровне БД получается, что не есть хорошо, отсюда вытекает то, что связи не нужны. Вообще, если перенести эту диаграмму в рабочую БД, то последняя видит только 4 связь из 4-х (то есть один из 4-х внешних ключей), что является верным решением, скажем так.
Что касается добавления новых типов (таблиц) - их просто нет больше, так что это не проблема. (В рамках моего проекта, скажем так)
Пу сути, это звучит глупо, но я пытаюсь сделать внешний ключ, который будет являться составным и учитывать в себе и тип (который находится вообще в другой таблице) и идентификатор типа, я не понимаю, как это сделать. Сделать так, чтобы внешний ключ ссылался на 2 таблицы сразу нельзя, уже прочитал и я в тупике.
Просто хочу делать хорошо, а не так, чтобы просто работало.
Ihor Kalashnikov: Если вы это имели в виду: i.imgur.com/OG1vUJs.png то да, ясно было изначально. Только то, что здесь нарисовано - чушь или же до меня не доходит.
sim3x: Нет. Пока она вообще не нужна. Пытаюсь разделить по категориям, чтобы было просто и удобно ориентироваться. Я сомневаюсь, что я на пути к денормализации. Взять в пример любой ИМ, все товары хранятся в одной таблице? В любом случае все делится на категории, у которых разные параметры. Взять юлмарт, который продает какие-нибудь материнские платы и гречку, вряд ли это хранится в одной таблице.
С эти разобрались, что надо добавить тип. Непонятно как связать таблицы. Потому что есть 4 типа транспорта - это 4 таблицы, в "главной" таблице содержится 3 поля: имя, тип и ид транспорта, если добавлять внешние ключи, то родителями будут выступать таблицы с описанием транспорта и все связи будут идти от поля ид транспорта - что работать не будет, потому что я не могу изменить через родителя значение другого родителя, да и мне это не требуется. Нужно как-то сделать чтобы учитывался тип, при изменении ID в параметрах транспорта.
Ihor Kalashnikov: Кажется, я не разобрался :) У меня выходит так, что у одного потомка есть 4 предка в "общей" таблице: user_id, auto_id, metro_id, bus_id, boat_id. Так работать не будет. Тут получается, что при смене ID родителя мы попытаемся сменить ID других родителей - бред какой-то.
Ihor Kalashnikov Выходит, что внешних ключей таблица не будет иметь или только на таблицу с типами? То есть таблицы с транспортом и объединяющая таблица "сами по себе" без связей?