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

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

Вторая идея - вынести в отдельную таблицу адресов и хранить там в форме id, city, street, house, apt. Но это не решает проблему вертикальной дупликации строковых значений: у меня будет очень много Москв и Санкт-Петербургов, например. Значит, нужно создать таблицу city и снова делать туда FK и потом JOINить все это дело. Улицы, по идее тоже бы неплохо хранить в своей таблице и связать их с теми городами, которым они принадлежат.

На самом деле уже получается довольно громоздкая БД для такого просто приложения (по сути простейшая CRM система). Вот и когда я уже дошел до такого состояния, что для выполнения простейшего запроса нужно сделать запрос в 3 JOINа на 4 таблицы, я заметил интересную вещь у меня вертикальную дупликация как минимум идет по именам: и вот я сейчас думаю, почему меня должно смущать, что у меня в таблице 2000 Москв, а 2000 Андреев - это нормально?

Или нужно создавать таблицу с именами? ;)

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

PizzaPizzaОсталось выяснить для чего нужна сама нормализация (ну не нужна же она только для галочки, правда?) и вы сразу получите ответ.

Вот это и непонятно. Т.е. почему email и телефон я храню в таблице user, а адрес этого user'а выношу в таблицу address? Вот читаю, например:

авторНормализация нужна для борьбы с избыточностью. т.е. данные не дублируются и связаны только внешними ключами.
Ок, допустим хранить имя клиента в таблице order - это глупо (у одного юзера может быть овер до черта заказов). Но в моем случае - адрес у него может быть только один. Где здесь дупликация?

В принципе тут вопрос, а является ли мой вариант в принципе не нормализованным. Смотрим по формам:
авторПервая нормальная форма:

запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию)
запрещает множественные столбцы (содержащие значения типа списка и т.п.)
требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку

Повторяющихся столбцов нет (номер дома и город - это не одинаковая по смыслу информация).
Множественных столбцов нет.
Первичный ключ есть. Дальше, аленькая ремарочка: если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во второй нормальной форме (мой pk - user_id, один столбец).

авторТретья нормальная форма

Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы неключевые столбцы в ней не зависели от других неключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте - это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц надо удалить.
Здесь непонятно: столбец город не зависит ни от первичного ключа, ни от других столбцов - никаким образом получить город пользователя из других столбцов нельзя.

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

О, книжка Харрингтона. Пацан складывает все в таблицу customer и не парится. Че, не нормализовано?