Доброй глубокой ночи)

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

Таблица пользователя:
id, city_id, university_id name

Таблица города
city_id name

Таблица вуза
university_id city_id(FK) name


Просто смущает, что если таких параметров много (причем некоторые как бы зависят друг от друга, типа город-вуз, а некоторые нет, например возраст) то будет много табличек и много столбцов у пользователя. Мне кто-то говорил что можно такие данные в XML хранить, но только я никогда почти его не использовал и поэтому не знаю.  И да, естественно должна быть возможность добавить новые города и т.д. 

И еще вспомнил - к пользователю крепятся теги, и соотвественно нужен поиск по тегам.. Про теги я думаю погуглю, а вот то что выше - правильный ход, или криво?

Сложно дать конкретный совет не видя всей функциональной структуры + не зная расчетной нагрузки

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

Какие вижу варианты решения
1. Создать промежуточную таблицу связей
2. Перечислять в одном поле ID всех школ через запятую
3. Создать дополнительную таблицу с результирующий выборкой

Какой из вариантов применить(а может вообще другой) будет ясно если опишешь в деталях что и как


Не о том ты думаешь


Не вижу плюсов

Ну вообще это я в качестве примера привел, у меня немного другой объект и другие поля. По большей части это местоположение. Типа город, район, тип помещения и т.п. И тут возможно что не будет множественных полей вообще.

Но на самом деле я как раз думал что будет если например много школ у человека. Единственное решение которое я на практике знал это разбивать связи N-N, типа еще одна табличка "учился в школе". При добавлении человека если он указал несколько школ то добавляем несколько записей в доп. таблицу. А когда хотим выяснить в каких школах он учился выбираем по айди пользователя из доп. таблицы все записи. Это вроде железный метод?) 
Никогда не думал хранить айди через запятую, хм
 
А это вообще не понял

Ну я на самом деле просто спрашиваю может глупые вопросы т.к. не хочу накосячить на старте. Мне часто кажется что всегда какие-то задачи делаются не так как я делаю  

Спасибо

Так будут множественные поля или нет  


Используй этот вариант


Это вроде внутреннего кэша, когда вся выборка уже сделана и отдается готовый результат. Оно тебе нафиг не надо

Ripper, Есть еще мысль, что если четко определить структуру поиска невозможно - то можно пользоваться текстовым поиском. Просто свалить все поля, по которым интересно искать в одно текстовое поле и проиндексировать его fulltext. Конечно, поля с четко понятным значением нужно бы выводить в отдельные таблицы...

Не когда больше не просите совета у этого человека.

Кол-во таблиц Вас пугать не должно. Как правильно организовывать данные в базе придумали уже очень давно и не стоит выдумывать велосепеды - большинство альтернативных вариантов рождаються от лени и нежелания разбираться. Почитайте про нормальные формы таблиц.