Нужно решить задачу по проектированию базы данных.
Есть ряд однотипных критериев например: /имя пользователя/ /телефон/ /возраст/
Необходимо разделить пользователей на группы например /Программисты/, /Высокие люди/, /Женщины/ - просто будем считать что группы разные друг с другом не связанные.
К каждой группе необходимо прикрепить ряд дополнительных критериев, например, для программиста /владение языками программирования/, /способность сидеть на стуле целый день/, для высоких людей: /рост/, /навыки игры в волейбол/ для женщин: /длина волос/, /объём бёдер/ и т. п.
Дополнительные условия:
1. По каждому дополнительному критерию, а также по общим критериям необходимо сделать возможность поиска.
2. Количество критериев может быть разным для каждой группы.
3. Типы данных также могут отличатся (BOOL TEXT INT)
4. Со временем критерии можно было бы добавлять или удалять.
Моё решение сейчас таково, чтобы под каждую группу создавать отдельную таблицу с необходимым набором критериев (в том числе общих для всех групп). Мне кажется это решение оптимальным с точки зрения скорости работы поиска и простоты реализации. Но таких таблиц со временем может накопится тысячи или десятки тысяч. Может быть есть другой способ?
Примечание:
Epsiloncool
Спасибо, я теперь знаю как это называется :)
LEFT JOIN я бы стал использовать только для таблиц до 10К значений, но в этом проекте нужно предусмотреть на несколько порядков большую нагрузку. Тем более если дело касается поиска по тексту.
Примечание:
Epsiloncool
>>Не понимаю, чем это left join так плох. У меня прекрасно работает на 10 миллионах записей.
1 left join всегда сканирует таблицу полностью Если данные проиндексированы и однотипны как в вашем случае, то всё хорошо. Но это сложно достижимо в моём случае.
2 Я давно зарёкся от его использования и вместо LEFT JOIN я всегда пользуюсь двумя+ запросами и сортировкой данных внутри PHP - эксперементально доказано, что это более быстрый способ.
А ещё небольшие массивы можно хранить в memcached и таким образом ими можно легче манипулировать, в том числе в плане полнотекстового поиска. С большими таблицами так не поступишь. И вопрос масштабирования о котором забываешь на этапе разработки, обычно клюёт в самый неподходящий момент. С большим количеством самостоятельных таблиц масштабирование довольно просто, а вот что делать с тремя огромными таблицами, которые нельзя разделить?
RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.
Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.
Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.