Какая локация, что за CPU ?
провайдер +id юзера = его логин в твоей системе
А возьмите листочек бумаги, да начертите логику, когда работа с двумя таблицами или с десятком.
Я уже свою точку зрения (как бы делал сам) высказал. Принять или нет - уже за вами.
Вам накидали вариантов развития плюсов и минусов, далее решайте сами.
edogs, у вас фактически 2 варианта:
1) хранить строго типизированную информацию в одной таблице
2) хранить просто информацию в двух таблицах, или как еще предлагалось в едином поле в виде json или другой структуры.
Хранить же в разных таблицах по типам данных - это бред. Выигрыша ноль, сложность большая. Но вы всегда в праве набить свои собственные косяки и шишки, тут спору нет :D
Москвичи редко город указывают, ибо жизни за мкадом нет. А на Украине даже вэбмани прикрыли, так что гривна едина по всей планете :D
Кстати похожей манией страдают англичане, они цены в фунтах указывают, даже когда рекламят свои услуги на мировой рынок.
Я тоже так раньше страдал, когда хотел сделать идеальный код. Но требования пользователей обламывали все мои старания, поэтому я стал делать проще и жить стало легче 🤪
В вашем "телефонном" случае сначала придет бухгалтер и поинтересуется "а как мне записать номер клиента, у которого надо дополнительно код внутренней телефонной станции вводить, т.е. 1452367(312). Вот так, как у него на визитке".
А далее из столовой ваш любимый шеф повар, с запросом "а как к телефону указать примечание [при звонке спросить Любу]".
И будете вы вечно туда сюда менять структуру таблицы, которая при ляме записей будет на пол часа зависать с операцией alter table и под конец вообще рухнет. А с innodb никаких repair table не предусмотрено 🙅
В то же время дай запись в виде text - и пускай туда хоть пароль к черту лысому пишут.
Если вы хотите хранить строго типизированную структуру - то делайте как на вашем скришоте. Если же просто хранить данные, делайте из двух таблиц. Задайте поле text или blob и живите спокойно.
Какой смысл делить на "VARCHAR(255) VARCHAR(50)", если для базы это один и тот же тип.
Строгая типизация нужна, когда вы работаете с жестко заданными данными. А вашем случае, структура из двух таблиц, будет имитацией nosql с выборкой по ключу.
Ну вытянете 100 связанных записей, не трагедия совершенно. Зато нормальная расширяемость при случае.
Понадобиться хранить фотографию, скан визитки контакта - в третью таблицу таким же образом, где уже blob поля.
У меня сейчас на одном из проектов за пару лет данных в похожей табличке, только с text полями, уже под 20 миллионов собралось. Выборка по индексированному varchar полю менее секунды. А по int первичному ключу вообще моментом.
Экономия на спичках в виде размера поля ничего не даст.
Сделайте структуру из двух таблиц, как вы и описали. Загоните туда приблизительный объем данных и посмотрите, как сервер себя будет вести.
Все равно поля юзера будете по ключу вытягивать.
Почему поле телефона int а не тот же varchar ? Телефоны могут по разному записываться http://stdcxx.apache.org/doc/stdlibug/26-1.html
