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

Почему поле телефона int а не тот же varchar ? Телефоны могут по разному записываться http://stdcxx.apache.org/doc/stdlibug/26-1.html

Stek, потому, что я храню не форматированный номер, а это число. К тому же, сайт предназначен для одного региона, поэтому, VARCHAR по сравнению с CHAR, INT не добавляет преимуществ (все поля, занимают ровно 12 цифр). Обсуждаем в соседней ветке.

Экономия на спичках в виде размера поля ничего не даст.

Сделайте структуру из двух таблиц, как вы и описали. Загоните туда приблизительный объем данных и посмотрите, как сервер себя будет вести.

Все равно поля юзера будете по ключу вытягивать.

Stek, но owner то один, а вот полей на 1 запись может быть вообще 100, а это 100 выборок. Вот сомневаюсь. Никогда не работал с сильно заполненными базами. 1 миллион записей, это как семечки щелкать? Вот у меня, например, на iPhone, есть программа Todo Pro. Раньше она летала, но стоило мне использовать ее один год, так теперь, даже списки с небольшим количеством задач, открываются по 3 секунды. Кстати, база там в SQLLite. Вот думаю, не ждет ли меня подобное?

Кто имел дело с таблицами InnoDB, где количество записей больше миллиона, пожалуйста, поделитесь впечатлениями. Я просто не в теме, но мне очень интересно! :)

Ну вытянете 100 связанных записей, не трагедия совершенно. Зато нормальная расширяемость при случае.

Понадобиться хранить фотографию, скан визитки контакта - в третью таблицу таким же образом, где уже blob поля.

У меня сейчас на одном из проектов за пару лет данных в похожей табличке, только с text полями, уже под 20 миллионов собралось. Выборка по индексированному varchar полю менее секунды. А по int первичному ключу вообще моментом.

Stek, выходит на каждый тип поля - своя таблица - свой запрос? То-есть, для номера INT нужно создать phone-entries? Насколько накладно, если вместо поля ENUM с типом записи, я создам табличку для каждого из типов записей (примерно 10 таблиц)? Например, те же записки к контакту имеют тип TEXT, не делать же мне все поля типом TEXT? Номер телефона INT(15), URL VARCHAR(255), а имя VARCHAR(50).

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

Потому что какой бы способ хранения контактов данных Вы бы не выбрали, выборка полей контактов по основному ИД юзера - будет практически мгновенной в любом случае.

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

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

Если нужен хитропоиск с исключениями по принципу "носящие желтые туфли, но не носящие красные", то eav вряд ли подойдет в принципе.

Если вы хотите хранить строго типизированную структуру - то делайте как на вашем скришоте. Если же просто хранить данные, делайте из двух таблиц. Задайте поле text или blob и живите спокойно.

Какой смысл делить на "VARCHAR(255) VARCHAR(50)", если для базы это один и тот же тип.

Строгая типизация нужна, когда вы работаете с жестко заданными данными. А вашем случае, структура из двух таблиц, будет имитацией nosql с выборкой по ключу.

Stek, ну пока что я решил привести таблицу к 3 нормальному виду. То-бишь, под каждое значение - своя таблица + строгая типизация для полей + учет. Критика?

Для хранения - нормально.

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

Для поиска - как Вы будете искать в контактах человека у которого в телефоне есть вхождение 812 (одна таблица), при этом он носит белые штаны (другая таблица) и никогда не был в рио-де-жанейро (третья таблица + негативная выборка) но при этом был в москве (третья таблица и позитивная выборка)? EAV усложняет эту задачу само по себе, а несколько таблиц забивают гвоздь в крышку гроба:)