Это хорошая схема БД для локаций

Question

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

Местонахождение

id                      -- int
formatted_address       -- varchar(200)
is_point_of_interest    -- bool
name                    -- varchar(100) -- NULL
street_number           -- varchar(10)  -- NULL
street                  -- varchar(40)  -- NULL
city                    -- varchar(40)
state                   -- varchar(40)
state_code              -- varchar(3)
postal_code             -- varchar(10)
country                 -- varchar(40)
country_code            -- varchar(3)
latitude                -- float(10,6)
longitude               -- float(10,6)
last_updated_at         -- timestamp

Вот несколько заметок о приложении:

• Я хочу держать дверь открытой для международных локаций
• Я планирую использовать службу геокодирования для поиска и проверки местоположений, указанных владельцем магазина
• Мне действительно нужен только широта / долгота, но для отображения информации о магазине необходимы другие данные
• Поле formatted_address будет содержать полностью отформатированный адрес - например, Giants Stadium, 50 NJ-120, East Rutherford, NJ 07073, США - чтобы упростить поиск сохраненных местоположений
• Возможно будет много повторяющихся полей, потому что каждая строка может иметь разный уровень детализации - например, 123 Main Street, City, State 12345 отличается от Main Street, City, State 12345, потому что у одного есть указанный номер улицы, а у другого нет

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

Кто-нибудь видит что-то не так или имеет какие-либо улучшения, учитывая то, что я упомянул? Я вижу, как эта таблица становится довольно большой.

Answer 1

Я так не думаю.Вот мой двухминутный краткий обзор:

Это очень плохо нормализовано. По крайней мере city -> country следует перенести в другую таблицу (и оттуда нормализовать).Я считаю, что почтовые индексы могут пересекать границы города (или я очень плохо помню);Мне неизвестен такой город, который пересекает государственную границу.

formatted_address является «оптимизацией» и, вероятно, должен быть вычисляемым полем: то есть все данные для его воссоздания должны существовать в другом месте .(Это означает, что теперь не нужно беспокоиться об этом.)

Удачное проектирование.

---

Простая "более нормализованная" форма просто делаетпредложенное выше:

LOCATIONS
location_id             -- int
is_point_of_interest    -- bool
name                    -- varchar(100) -- NULL
street_number           -- varchar(10)  -- NULL
street                  -- varchar(40)  -- NULL
city_id                 -- int
postal_code             -- varchar(10)
latitude                -- float(10,6)
longitude               -- float(10,6)
last_updated_at         -- timestamp

CITIES
city_id                 
name                    -- varchar
-- similarly, the following should be normalized to STATES and COUNTRIES
state                   -- varchar(40)
state_code              -- varchar(3)
country                 -- varchar(40)
country_code            -- varchar(3)

Конечно, CITIES могут быть дополнительно нормализованы, и поэтому может таблица POSTALS: я не знаю достаточно ни о почтовых кодах, ни о предметной области приложения.postal_code действует как часть неявного составного-суррогата-ФК, так что это не супер ужасно , как там.Однако перемещение его в отдельную таблицу может легко допустить ограничения проверки и целостности.

Редактировать: Лучше всего будет нормализовать таблицу POSTALs, поскольку допустимо только очень небольшое количество почтовых кодов дляданный город: я не уверен в связи между почтовым индексом и городом, поэтому не могу рекомендовать, как это сделать.Возможно, посмотрите на существующие схемы?

Answer 2

Поскольку вы говорите: «Мне действительно нужен только лат / долг», я советую вам использовать 2 таблицы с соотношением 1: 1.

Во многих (большинстве?) Случаях будет кэшировано ОЧЕНЬ больше пар лат / долг, что ускорит вашу рабочую лошадку.Если вам нужна дополнительная информация, получите ее тогда, когда вам это нужно.

Краткая форма: не заставляйте БД перемещать ненужные данные через ввод-вывод и ОЗУ

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