Форум MySQL

Приветствую всех!

Есть БД, структура следующая:

id_pos position specialization money employment

Подскажите какую структуру должна иметь БД, чтобы в нее можно было занести сразу несколько позиций специализации (как на скриншоте), а затем осуществлять поиск по ним.

Есть идеи с serialize, а затем unserialize и прочими костылями, но они как-то все не подходят и очень неудобные. Хотелось бы услышать Ваши варианты...

Если количество специализаций не будет расти и их не нужно будет модифицировать можно использовать тип ENUM, но лучше их сразу вынести в отдельную таблицу, а в исходной оставить ключ id_specialization, который будет ссылаться на первичный ключ этой новой таблицы со специализациями.

PS Сериализация, строки через запятую - это действительно очень плохая идея и по производительности и по удобству использования. Сериализация она вообще с реляционными базами плохо сочетается - это механизм объектно-ориентированного подхода, эти два подхода в общем схожие задачи решают разными методами и имеют фундаментальные противоречия. Поэтому в точке перехода данных из ООП в базу данных, вы либо теряете преимущества базы данных - строка хранится сериализованной и механизмы базы данных не работают, либо преимущества ООП - вам нужно разобрать объект по винтику и сохранить как реляционную модель, либо писать каждый раз громоздкий фасад для коннекта. Если у вас там не сильно густо ООП, лучше не терять преимущества реляционной базы данных, механизмами, которые вам в общем не очень и нужны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

для таблиц :

id_pos
position
money
employment

id_spec
specialization