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

Пока что пришел к итогу использовать следующую структуру. Все поля, кроме password, могут быть только в единичном экземпляре на одну запись. Пароли сохраняются в отдельной таблице и их может быть неограниченное количество. К паролю можно задать label, поэтому, можно также сохранять "секретные" вопросы: label - вопрос, password - ответ. email, phone берется с owner, если не задан другой.

Пока что, как по мне, это компромиссное решение. Здесь нету маразматического количества таблиц, но зато, теперь я могу прикрепить все своих 3 почтовых адреса, задать все пароли Google 2-step app login.

Кроме того, если я удаляю аккаунт, я просто изменяю его status на false. Можно отображать отключенные записи на протяжении, например, 1 месяца (именно это мотивирует date-modified).

Еще не придумал, как идентифицировать OAuth? Просто указывать на пароль от Facebook с label Facebook?

Вы ни разу не написали, какие выборки по этому полю вы планируете делать (или я невнимательно читал)

От этого зависит правильный ответ на ваш вопрос.

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

Вообще, если у вас в таблице не миллион строк, используйте любой тип. На производительности вряд ли заметно отразится.

---------- Добавлено 14.09.2013 в 00:23 ----------

Хм... это я так неудачно запостил ответ на вопрос "char или int" :)

Перепутал кнопки.

ortegas, та штука, которая получится в итоге, полюбому должна называться SearchCMS

dkameleon, SearchCyberStackCMS даже. :)

Спасибо всем. Может кто-то додумается, как можно хранить пасскарту, где вместо пароля авторизация через OAuth? Как-то скреплять карточки?

провайдер +id юзера = его логин в твоей системе

Stek, это не учетная запись, а пасскарта. Менеджер паролей, типа LastPass.