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

Вот, предположим, у Вас регистрируется Иван Иванович Иванов с адресом "1-я Парковая ул., дом 2, кв 18". Потом регистрируется
Нина Петровна Иванова с тем же адресом - надо понимать, Вы новой записи в таблице "адрес" не создается, а Нине Петровне ставите ссылку на ту же запись, что Ивану Ивановичу? Теперь внимание - Иван Иванович решает изменить свой адрес на "1-я Парковая ул., дом 2, корп. 1, кв 18" - что Вы делаете?

vadiminfoКот МатроскинКстати, в таких многопользовательских базах подходами к нормализации "из учебника" надо пользоваться с осторожностью.
Возможно, следовало бы уточнить:
1 как связана нормализация с многопользовательностью.

Ну так в примере я и постарался показать, как они связаны.
Если удаляться в теорию - Дейт обсуждал ситуацию, когда у нас есть набор непреложных фактов, и наша задача - отразить их в БД оптимальным образом. Мы знаем , что в бухгалтерии изменился телефон, и гораздо удобнее отразить этот факт в одной записи, чем у всех сотрудников бухгалтерии.
А в базах, где регистрируются и которые наполняют 100500 хомячков, руководствуясь какими-то своими резонами - с непреложными фактами дело обстоит по-другому. Вот в описанном случае - знаем ли мы, что реальный адрес Ивана Ивановича и Нины Петровны изменился? Или это просто Иван Иванович решил выпендриться? Или на самом деле действительно есть отдельный адрес с корпусом, и на самом деле Иван Иванович съехал в соседний дом от опостылевшей жены?
У нас есть другие непреложные факты - 1. Иван Иванович изменил свою инфу 2. Нина Петровна не сочла нужным это сделать.
И для отражения этих фактов стандартный подход с выделением ФЗ в инфе - едва ли не мешает.

vadiminfoКот Матроскинпропущено...

Ну так в примере я и постарался показать, как они связаны.
Если удаляться в теорию - Дейт обсуждал ситуацию, когда у нас есть набор непреложных фактов, и наша задача - отразить их в БД оптимальным образом. Мы знаем , что в бухгалтерии изменился телефон, и гораздо удобнее отразить этот факт в одной записи, чем у всех сотрудников бухгалтерии.
А в базах, где регистрируются и которые наполняют 100500 хомячков, руководствуясь какими-то своими резонами - с непреложными фактами дело обстоит по-другому.
Вообще-то первая БД тоже, обычно, относятся к многопользовательским: может ондновременно работать несколько пользователей.
Больше одного: возможны конфликты и взаимное влияние.

Под свойством базы "многопользовательская" я имел в виду не количество одновременных коннектов к БД.


vadiminfoКот МатроскинВот в описанном случае - знаем ли мы, что реальный адрес Ивана Ивановича и Нины Петровны изменился? Или это просто Иван Иванович решил выпендриться? Или на самом деле действительно есть отдельный адрес с корпусом, и на самом деле Иван Иванович съехал в соседний дом от опостылевшей жены?
У нас есть другие непреложные факты - 1. Иван Иванович изменил свою инфу 2. Нина Петровна не сочла нужным это сделать.
И для отражения этих фактов стандартный подход с выделением ФЗ в инфе - едва ли не мешает.
Т.е. не " стандартный подход " это просто типа денорамализация?
Нет.
Нормализация - это устранение избыточности и возможности аномалий при обновлении данных.
Выделение адреса в отдельную сущность в описанном случае не ведет к устранению избыточности и аномалий обновления, следовательно, не является нормализацией.

sdetКот Матроскинпропущено...

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

Ну я про это и говорю - ни от каких аномалий обновления в сравнении с хранением в основной таблице не избавились, + получили дополнительные проблемы с проверками "А есть ли еще у кого-то такой же адрес?".

sdetОднако, такой вариант позволяет выбирать города, страны и т. д. из справочников(dropdown), убирая аномалии и spelling проблемы, а также делать distinct из большой таблицы. Дает возможность использовать адреса на разные объекты и хранить историю.

??
Неясна связь организации UI и хранения данных в БД. Кто Вам мешает делать выбор из справочников в случае хранения в основной таблице? Кто мешает "делать distinct из большой таблицы" (что бы это ни значило и для чего бы ни было нужно)?
Кто мешает хранить историю по большой таблице?

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


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

fourEyes,

Уникальные тэги для каждого поста не очень осмысленны - поскольку поиск по ним, очевидно, проводить нельзя.