Здравствуйте. У меня есть необходимость хранить в базе MySQL такие поля пользователя как: - имя (поле input) - фамилия (поле input) - email (поле input) - страна (поле select) - род деятельности (поле select) - специализация (поле select multiple) - сопутствующая информация (поле textarea) По всем этим полям в будущем будет работать поиск. Как правильнее хранить эти данные в базе, чтобы в будущем, когда записей станет несколько тысяч, при выводе на экран данных профиля а также при поиске по отдельно взятым полям ничего не тормозило? Раньше я делал это так. Делал отдельную таблицу users, и в ней были все эти поля: lastname (varchar 50) firstname (varchar 50) email (varchar 50) country (varchar 50) work (varchar 50) spec (text) information (text) Но когда записей стало очень много, все начинает тормозить при выводе на экран. Первое что приходит в голову, в таблице users хранить только числовые значения (int), ссылающиеся на ID записей в других таблицах. Например вот так хранить страну в таблице users: country (int 10) и создать отдельную таблицу со странами, например таблицу country: id (int 10) name (varchar 50) Но в этом случае у нас становится больше обращений к базе. Ведь если будут читаться все поля профиля, то обращений будет очень много. Нужно Ваше мнение, в какую сторону правильнее двигаться для того чтобы не тормозило при большом количестве записей. Может есть еще какие способы. Заранее спасибо!
несколько тысяч таких записей - это ни о чем! даже миллион .. так что не верю насчет тормозов - если вы только не выводите ВСЕ ... тогда да... там сам вывод тормозить будет. Обычно используют пагинацию... то есть вывод постранично по тому что часть полей можно и нужно вынести в справочники - верный подход... позволит избежать разночтений в названиях стран и поиск по числовому индексу быстрее безосновательное утверждение - JOIN в запросе и все.... запрос как был 1 - так и будет 1
Спасибо за ответ. Скажите пожалуйста. 1. У меня в системе идет авторизация по email. Имеет ли смысл хранить email-ы также в справочнике, в отдельной таблице, а в таблице users лишь ID записи в справочнике, или это уже перебор? 2. Как хранить денежные суммы с копейками, центами а также в случае если это крипта, где количество символов после точки может быть больше двух. В процессе работы, суммы будут складываться, умножаться, вычитаться и делиться, чтобы это было удобно и не было бы потерь дробях. Склоняюсь к DECIMAL, но может есть что лучше.
Это перебор, лучше ID и email пользователей в одной табличке держать... Я использую DECIMAL и для двух знаков после запятой, и для трех. Проблем с этим не наблюдал...
Имена, фамилии (несмотря на наличие тезок ), email'ы хранят в осн. таблице. Поле с email'ами – юник, т.е. должно иметь уник. ключ.
--- Добавлено --- Был вариант в игрушке, когда пользователь передал свой email сыну, а себе завёл новый ник с новым мылом. Был вариант в организации, когда служебным адресом пользовался один человек, потом другой. Лучше всё-таки поставить проверку, что не может быть двух активных юзеров с одним мылом. А неактивных - сколько угодно. Впрочем, зависит от задачи. --- Добавлено --- Если теоретически возможно в перспективе добавление других емейлов (запасных, для безопасности и т.д.) - надо в отдельной. А так - конечно в общей.
Я только про «активных». У «неактивных» можешь не использовать юник, размещая их в отдельной таблице. Это же просто архив --- Добавлено --- Вдаваться в детали и спрашивать, что такое «(не)активные», не буду. Надеюсь, под «неактивными» подразумеваются какие-то «невозвратные», так что их вообще можно грохнуть/не хранить в основной БД.