Как лучше сохранять записи (через связку или нет)?

[danneo]

MySQL + php.
Пользователь добавляет автомобиль на сайт. Авто имеет свою таблицу в БД. Сначала добавляет свое такси (фирму), а далее привязывает определенную свою машину к определенной своей фирме.
Но... может же быть, что одна и та же машина работает в двух фирмах?
Соответственно, можно сохранять в поле id_firm несколько значений фирм - 1,2,3 и т.д.
Также можно добавлять на одну фирму отдельную машину, независимо, одна и та же или нет. Так проще всего для меня , но для пользователя чуть "напряжнее".
А можно через еще одну таблицу-связку, например, tb_auto_firm (id, id_firm, id_auto). Вроде как так правильнее. Но мне кажется, лишний труд.
Как можно определить какой вариант будет лучше?

 

[Rollo]

с точки зрения классического проектирования БД то да, промежуточная таблица

в зависимости однако от нагрузки вы можете сделать поле типа SET и класть туда ИД фирм, но имхо с промежуточной таблицей при большом кол-ве записей выборка будет быстрее

 

[tinku]

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

 

[Rollo]

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

Если ві имели в виду внешние ключи то да, конечно. Связь между полями тут логически предполагается

 

[Шумадан]

MySQL + php.
А можно через еще одну таблицу-связку, например, tb_auto_firm (id, id_firm, id_auto). Вроде как так правильнее. Но мне кажется, лишний труд.

ну классика же, + уникальный ключ на (id_firm, id_auto), id - автоинкремент. и абсолютно не лишний труд. скажем, Кохана на таких таблицах и строит множественные связи, причём в обе стороны, как по машине, которая принадлежит многим фирмам, так и фирме у которой может быть много машин

 

[tinku]

Если ві имели в виду внешние ключи то да, конечно. Связь между полями тут логически предполагается

Да, именно их. Логически-то предполагаются, а вот делаются они не всегда. Потом разбирать бардак за такими "спецами" не люблю..

 

[Rollo]

Да, именно их. Логически-то предполагаются, а вот делаются они не всегда. Потом разбирать бардак за такими "спецами" не люблю..

иногда девы их не делают для того чтобы на черновую внести данные для тестов. их консистентность не так важна,
важно не забыть добавить их потом
также, поддержка Foreign keys пригружает базу на больших объемах insert. не так чтоб очень, но эффект есть, я натыкался на статью где люди тестили с/без какое-то время назад, разница в несколько % на более-менее адекватных схемах при адекватных объемах данных
это может быть важно на сервере с уровнем загрузки под потолок, в остальных случаях...

 

[tinku]

иногда девы их не делают для того чтобы на черновую внести данные для тестов. их консистентность не так важна,
важно не забыть добавить их потом
также, поддержка Foreign keys пригружает базу на больших объемах insert. не так чтоб очень, но эффект есть, я натыкался на статью где люди тестили с/без какое-то время назад, разница в несколько % на более-менее адекватных схемах при адекватных объемах данных
это может быть важно на сервере с уровнем загрузки под потолок, в остальных случаях...

Может быть. Не знаю. Я для себя даже в черновых вариантах делаю ключи, во-первых, сразу видно что, где и как работает, а во-вторых, точно не забуду потом ничего.
А гнаться за %%, вот этого я точно не понимаю. Забить на целостность базы ради, пусть даже, 3%? Экономически нецелесообразно. Да и при таком раскладе в коде необходимо делать дополнительные проверки которые съедят значительно больше.