Здравствуйте!
При проектировании БД возник вопрос , как можно более удачно организовать хранение данных в такой ситуации, или существует ли шаблон для похожих решений, чтобы не изобретать велосипед...
Есть таблица пользователей с полями
user_id
username
music SET(music1,music2,.... musicN)
hobby (hobby1,hobby2,... hobbyN)
...
в таблице присутствует около 20ти колонок с типом SET с различн. значениями, по которым я потом буду осуществлять примерно сл. поиск:
поиск пользователя с музыкой music1 и music2 и с хобби hobby5,hobby8... и т.д...

softwarerЕсли SET имеется в виду как домен, а-ля битовый вектор на основе чётко заданного списка вариантов, то не очень понятно, в чём Вы видите проблему. Если же Вы имеете в виду необходимость хранить до N записей из произвольного справочника, то есть такой шаблон, называется "первая нормальная форма".

Извнените, я просто БД проходил только в универе и то... так... )) И многих понятий не знаю... пытался найти что-нить по паттернам проектирования БД, но не нашел (((

Если первый(фиксированный список) не будет ли кушать много ресурсов при поиске если у меня таких колонок штук 20 и в каждой ~10 значений, записей в таблице >500к.

Насчет второго варианта если например у меня будет 20 колонок и в каждом будет выбираться например 8 значений то при 500к пользователей таблица получиться 80кк... или например тогда следует создать для каждой колонки свою таблицу зависимостей...?

Злой Бобрalexis1984,

Тут вопрос скорее сводится к тому что вам потом потребуется хранить что-то еще кроме названия. Поэтому предлагаю сделать отдельную таблицу music(id, name, ...) и связать ее с пользователем (если честно мне непонятно - зачем?) user_music(id_user, id_music).

Не понятно зачем делать связь с пользователем или что???

Я хочу реализовать следующую вещь.... может мой подход вообще не верный... просто я додумался только до такого подхода)
профили пользователей и у них есть
секция интересы:
в этой секции есть группировки интересов:
например музыка, хобби...
в каждой группировке N количество чекбоксов со значениями(для каждой группировки свои)
вот... и мне нужно организовать хранение этих значений а также поиск пользователей по этим значениям....
Надеюсь более менее понятно объяснил...
Как я понимаю такой принцип используют и в дневниках когда используют теги и поиск по тегам, также используют в сайтах знакомств и соц сетях....

Злой Бобрalexis1984,

Ну это меняет дело. Тогда сказанное мною вам ненужно.
Определитесь четко с деревом и создайте под него таблицу с id. В таблице пользователей создайте поле в котором будете хранить id выбранных пользователем категорий. Поиск по содержимому этого поля. Но вам нужно четко понимать что чем больше будет дерево, тем медленнее поиск. Поэтому если планируется изначально большое дерево лучше сделать или несколько фиксированных полей под определенные категории (но это затруднит в дальнейшем операции с деревом, в принципе примерно то что вы предложили в первом посте), или таблицу user_cat(id_user, id_cat). По какому пути пойти выбирать вам.
Да, решил использовать второй способ! Спасибо!