[SQL] Хранить связи
имхо одна фигня, но имхо не стоит заводить лишних полей там, где они не нужны...
Имхо сильно зависит от БД.
Например не все СУБД нормально переваривают длинные текстовые ключи, снижается производительность.
Тогда имеет смысл ввести отдельный числовой ключ.
Если a_id и b_id - числа, то лучше пользовать вариант 1 и не плодить лишних сущностей.
Например не все СУБД нормально переваривают длинные текстовые ключи, снижается производительность.
Тогда имеет смысл ввести отдельный числовой ключ.
Если a_id и b_id - числа, то лучше пользовать вариант 1 и не плодить лишних сущностей.
a_id и b_id - числа.
Раньше использовал именно первый вариант, но почему-то во всех чужих решениях вижу именно второй... вот и задумался, а чем он так хорош (точнее, чем так плох первый что все его используют?
Раньше использовал именно первый вариант, но почему-то во всех чужих решениях вижу именно второй... вот и задумался, а чем он так хорош (точнее, чем так плох первый что все его используют?
Кто все? Вот я тоже всегда первый вариант использую. Это, имхо, как раз стандартное решение.
+1
первый вариант, если, конечно, нет необходимости хранить в какой-нибудь таблице атрибут, указывающий на данную связь, или создавать схему согласно Дейту.
Оставить комментарий
kruzer25
Как быстрее будет работать?Варианты:
1) Поля a_id, b_id, объединённые в первичный ключ;
2) Поля id (первичный ключ); a_id, b_id, объединённые в уникальный ключ?
Ну и, конечно, в обоих вариантах - индекс на a_id и на b_id.