Форум MySQL

в любом случае две или три таблицы это обратимые процессы
и корректировка запросов не составит особого труда
хотя провести денормализацию (из трех сделать две таблицы) конечно проще
___
посмотрел еще раз скриншот
думаю точно три таблицы
так, что мои разглагольствования по поводу двух таблиц это теоретическо-лирическое отступление :)

>если 100% уникальность специализаций, то сами понимаете это не аргумент
Оно 100% на момент проектирования... а потом начинаются изменения, повторное использование кода... если проект будет жить не больше года, да, можно, но лучше все-таки не экономить место... заранее угадать где нужна экономия, а где вредит, практически невозможно, сложность слишком быстро возрастает и узкие места проявляются там, где ну никак не ожидаешь.

если специализации по большей части унифицированы, то отношение многие ко многим
реализуется как мы и говорили при помощи таблицы связи:

id_pos
id_spec
с первичным ключом на оба поля

для таблиц :

id_pos
position
money
employment

id_spec
specialization

я с точки зрения экономии места, да и запросы будут чуть проще
а при обслуживании одно дополнительное поле на которое можно не обращать внимание вряд ли помешает

в базе данных поменял - поменялось везде
если 100% уникальность специализаций, то сами понимаете это не аргумент

вот тут и нужно решить что более приоритетно две или три таблицы
и иногда такие вещи решаются только эксперементальным путем
но это чаще всего при уникальности специализаций около 50-70%

Неудобно обслуживать, с тремя таблицами названия хранятся в одном месте, в случае чего даже без интерфейса прямо в базе данных поменял - поменялось везде.

хотя если специализации по большей части уникальны, то можно (а впрочем даже нужно) обойтись двумя таблицами
тогда из первой таблицы убираем поле specialization
id_pos
position
money
employment

а вторая таблица будет иметь вид
id_spec
id_pos
specialization

Я, кстати, тоже, хотя и кажется, что вроде работы больше, но в конце концов проблем оказывается меньше, а система более масштабируемая.

можно повесить первичный ключ на оба поля таблицы связи
и о дубликатах не беспокоится
я лично целиком за вариант с таблицой связей

Ага, не сразу понял тогда, либо вместо ENUM использовать SET - он как раз позволяет несколько значений одновременно хранить (но не больше 64). Если же реализовывать табличный вариант, то помимо таблицы специализации нужно ввести еще одну таблицу для связи, с двумя столбцами: один - первичный ключ исходной таблицы (будет несколько повторяющихся) - другой первичный ключ таблицы специализации (тоже будут повторяющиеся но для одного ключа исходной таблицы все значения будут уникальны).

Вот в том-то и вопрос: будет несколько специализаций, как их к id_specialization прикрепить?

выкладывал в первом посте скриншот, но на всякий случай перезалил его в другое место. в первом посте его плохо видно. http://s011.radikal.ru/i316/1201/10/b390f4fc3ab2.jpg