SQL Архитектура хранения контактов

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

В вашем "телефонном" случае сначала придет бухгалтер и поинтересуется "а как мне записать номер клиента, у которого надо дополнительно код внутренней телефонной станции вводить, т.е. 1452367(312). Вот так, как у него на визитке".

А далее из столовой ваш любимый шеф повар, с запросом "а как к телефону указать примечание [при звонке спросить Любу]".

И будете вы вечно туда сюда менять структуру таблицы, которая при ляме записей будет на пол часа зависать с операцией alter table и под конец вообще рухнет. А с innodb никаких repair table не предусмотрено 🙅

В то же время дай запись в виде text - и пускай туда хоть пароль к черту лысому пишут.

Нормальные формы как раз и созданы, чтобы максимально защитить целостность данных.

В том то и дело. Мне реализовать мои идеи идеально намного легче, чем с костылями. Но я думаю о производительности сервера, поэтому, рассматриваю и варианты с костылями.

Уволю. К каждому контакту можно добавить заметки. Пиши там что хочешь.

Так и сделал.

Вы немного не верно смысл нормальных форм понимаете в данном контексте.

Нормальные формы фиксят ситуацию вида "имя васи хранится в двух местах" принципом вида "пихнем имя васи в одно место и сделаем на него ссылки". Тем самым изменяя данные васи их не нужно апдейтить данные в двух местах, достаточно в одном, поэтому целостность улучшается.

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

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

edogs, понимаете, на самом деле это не менеджер контактов, а менеджер паролей. Контакты я привел, чтобы лучше понималось. Да и не хотелось затрагивать алгоритмы хранения приватной информации.

У меня сейчас все пароли хранятся в текстовых файлах. И я каждый раз пишу номер телефона, каждый раз пишу свой один из трех почтовых ящиков, каждый раз пишу свое имя. Здесь же, есть возможность добавить универсальный email, имя вообще брать с имени owner, а для шифрования пароля использовать, как хеш owner (как уникальную для каждого пользователя соль) + свой пароль, который нигде, кроме cookie сохранятся не будет.

Вполне возможно, что система будет использоваться публично. Поэтому, owner обязателен. Обязателен он еще потому, что я люблю хранить приватную информацию других людей. Мне известны и пароли, и номера кредитных карт знакомых, и хранить я их собираясь, создав отдельного owner в своей системе. Контактная книга тоже будет. Это и есть список owner. Owner будет связан с контактной книгой, которая будет иметь синхронизацию с iCloud, FB.

Снова-таки, реализовать синхронизацию с iCloud, без этой абстракции, не выйдет.

Чтобы не создавать новую тему, спрошу. Есть ли смысл, использовать TINYINT, когда явно указываешь размер. То-есть, TINYINY против INT(3)?

edogs, у вас фактически 2 варианта:

1) хранить строго типизированную информацию в одной таблице

2) хранить просто информацию в двух таблицах, или как еще предлагалось в едином поле в виде json или другой структуры.

Хранить же в разных таблицах по типам данных - это бред. Выигрыша ноль, сложность большая. Но вы всегда в праве набить свои собственные косяки и шишки, тут спору нет :D

Сложность чего? Производительность кода сильно упадет?

У int-овых типов данных, в отличии от текстовых полей, число в скобках отношения к размеру занимаемых данных не имеет никакого, оно упрощенно говоря несет в себе чисто декоративный смысл в данном контексте.

edogs, спасибо. Даже не декоративное, а максимальное количество цифр.

По мануалу да, но непонятно где и как используется на практике. tinyint(1) вполне себе нормально хранит число 120.

Единственное где это вроде бы еще важно, это при джоинах таблиц по индексам. int (10) с int (11) вроде как не идеально склеивается по индексам. Но не вдавались в детали.

А возьмите листочек бумаги, да начертите логику, когда работа с двумя таблицами или с десятком.

Я уже свою точку зрения (как бы делал сам) высказал. Принять или нет - уже за вами.

Вам накидали вариантов развития плюсов и минусов, далее решайте сами.