Какая нормализация для адреса лучше?

Question

Сегодня у меня есть таблица, содержащая:

Table a
--------
name
description
street1
street2
zipcode
city
fk_countryID

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

Table A
--------
name
description
fk_streetID
streetNumber
zipcode
fk_countryID

Table Street
--------
id
street1
street2
fk_cityID

Table City
----------
id
name

Table Country
-------------
id
name

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

Аргумент "за" заключается в том, что это пойдет на снижение производительности при поиске и возможном дублировании.

Мне интересно, как лучше сюда идти.

ОБНОВЛЕНИЕ

Я стремлюсь иметь 15.000 брендов, связанных с 50.000 магазинов, где 1.000 пользователей будут выполнять многократный поиск каждый день по сети и iPhone. Кроме того, у меня будут 3. стороны, извлекающие данные из БД для своих сайтов.

Сайт еще не запущен, поэтому мы не имеем понятия о рабочей нагрузке. И когда мы начнем, у нас будет только около 1000 брендов, связанных примерно с 4000 магазинами.

Answer 1

Мой стандартный совет (из многолетнего опыта работы с хранилищами данных / BI) здесь:
всегда хранит самый низкий уровень разбитой детализации , т.е. опция нескольких полей.

В дополнение к этому, в зависимости от ваших потребностей, вы можете добавить индексы или даже составное поле, которое объединяет два других поля - хотя убедитесь, что поддерживаете с триггером, а не вручную, или у вас будет синхронизация данных ипроблемы с качеством.
Часть правильного ответа для вас всегда будет зависеть от вашего фактического использования.Можете ли вы когда-нибудь ожидать, что вам потребуется адрес в стандартном (2-строчном) формате для рассылки ... или обмена с другими организациями?Или это действительно чистая база данных «только для чтения», которая просто настроена для запросов и не используется для более стандартных потребностей в адресах, таких как рассылки.

В конце дня, если у вас есть проблемы с производительностью запросовВы можете добавить дополнительные структуры, такие как составные поля, индексы и даже другие таблицы с теми же данными в другой форме.Тогда есть также варианты для кэширования на уровне сервера, если производительность низкая.Если вы создаете сложный сайт или сайт с интенсивным трафиком, скорее всего, вы в конечном итоге получите продукт, который поможет, например, в мире программирования на Ruby люди используют продуманный сфинкс Если производительность запросов все еще остается проблемой, а ваши данныеВ будущем вам, возможно, придется рассмотреть решения, не относящиеся к SQL, такие как MongoDB .

И еще один последний принцип, которого я также придерживаюсь: подумайте о людях, которые обновляют данные, если это произойдет в этой системе.Когда люди вводят данные вначале, а затем впоследствии переходят к редактированию этой информации, они ожидают, что эта информация будет «одинаковой», поэтому любая внутренняя манипуляция, которая фактически изменяет форму или содержание ввода пользователя, станет большой головной болью при попытке разрешить имсделать простое редактирование.Я видел безумно сложные алгоритмы кодирования и декодирования данных таким способом, и у них часто бывают проблемы.

Answer 2

Я думаю, что самый верхний пример - это путь, может быть, с третьим полем свободной формы:

name
description
street1
street2
street3
zipcode
city
fk_countryID

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

Answer 3

Обратите внимание, что высокая нормализация означает больше объединений, поэтому она не приведет к более быстрому поиску в каждом случае.

Answer 4

Как уже упоминали другие, нормализация адресов (или «стандартизация») наиболее эффективна, когда данные объединены в одну таблицу, а отдельные части находятся в отдельных столбцах (как в первом примере).Я работаю в поле проверки адресов (на SmartyStreets), и вы обнаружите, что стандартизация адресов является действительно сложной задачей.Здесь больше документации по этой задаче: https://www.smartystreets.com/Features/Standardization/

Учитывая объем запросов, которые вы будете обрабатывать, я настоятельно рекомендую вам убедиться в правильности адресов перед развертыванием.Обработайте ваш список адресов и удалите дубликаты, стандартизируйте форматы и т. Д. Поставщик, сертифицированный CASS (например, SmartyStreets, хотя есть и другие), предоставит такую ​​услугу.