Який універсальний спосіб зберігати географічну адресу / місцезнаходження в базі даних? [зачинено]

Який правильний формат географічної адреси / місця розташування найкраще підходить для будь-якої адреси на Землі? На даний момент у мене є:

• країна
• місто
• вулиця
• число
• текстові дані (для простоти)
• блискавка
• lat / lng

Але я вважаю, що можу це вдосконалити: може бути держава / регіон країни чи щось подібне. Або немає району / регіону / штату, скажімо, в Сінгапурі чи Гонконзі.

Тут може бути не вулиця, а дорога, бульвар чи щось інше. Кілька будівель може бути складною. Там може бути слово. Номер кімнати. І т.д.

Google розробила бібліотеку, яка допомагає перевірити поштові адреси для кожної країни світу, за допомогою якої можна створити схему для зберігання цих даних.

Шукайте найпоширеніші обов’язкові поля для адрес з вашої цільової клієнтської бази, щоб розпочати роботу, і, як ви визначаєте подальші країни з різними вимогами, ви можете продовжувати коригувати схему.

Універсальний спосіб зберігання географічної адреси / місцезнаходження в базі даних:

[Address] nvarchar(max) not null

Для цього потрібна найменша кількість програмного коду (а це зменшує витрати на обслуговування) і повністю сумісна з будь-якою адресою. Однак у нього є три великі проблеми:

• Відсутність перевірки даних означає, що поле можна використовувати для інших цілей, ніж для збереження адреси. Однією з цілей є DOS-атака, призначена заповнити простір вашої бази даних, ввівши 2 ГБ даних у адресне поле.

• Дані, що зберігаються таким чином, унеможливлюють їх обробку з метою бізнес-розвідки та обміну даними. Наприклад, скільки користувачів з Індії? Простий спосіб сказати це не існує, оскільки ці адреси не будуть нормалізовані.

• Користувачі можуть помилково ввести неповну або явно неправильну адресу.

Щоб пом'якшити перший випуск, обмежте поле тим, що вважаєте розумним. Особисто я почав би з 1000 символів, а потім зменшив би його, виходячи з довжини адрес, введених першими користувачами, як тільки ви отримаєте набір даних досить великий.

Щоб пом'якшити дві інші проблеми, ви можете скористатись стороннім API, який аналізує адреси та представляє вам дані, що містять країну, місто, поштовий індекс тощо. Якщо можливо, API повинен мати змогу відображати адресу на повернення картці до користувача, щоб зменшити ризик для користувача ввести неповну або неправильну адресу: більшість користувачів знають, де вони живуть, і побачивши іншу позицію на карті, це негайно дасть їм зрозуміти, що вони повинні перевірити свій внесок.

Зауважте, що який би API ви не використовували, він не буде ідеальним. Він знайде більшість адрес, але не всі. Це означає, що якщо API повідомляє, що адреса не існує, але користувач наполягає на тому, щоб це було, ви повинні апріорі довіряти користувачеві, навіть якщо він може помилитися.

Це також означає, що ви все одно повинні зберігати вихідний вхід користувача, поруч із результатом API. Це означає, що схема стає:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

Немає жодної.

Кожна країна має різні формати адрес. Якщо вам пощастить, а у них взагалі є формат!

Очевидно, що широта / довгота дасть вам точку на земній кулі, але це не дуже корисно для визначення окремих будинків. Просто розглянемо, наприклад, блок вежі.

Ваша найкраща ставка - перевірити офіційну форму поштової служби для кожної країни. Це може бути чудово для вашої бази даних. Але вам, мабуть, доведеться спростити його для кінцевих користувачів, оскільки він буде містити набагато більше полів, ніж більшість людей звикли.

Наприклад, Великобританія включає такі речі, як "подвійний залежний населений пункт", але ніхто не знатиме, що це означає, якби ви запитали їх.

Єдиний універсальний формат - це мати єдине текстове поле, яке може мати кілька рядків тексту. Це дозволить отримати будь-яку можливу адресу на землі.

Я розробляю програмні рішення, які використовуються в багатьох країнах. Ми вирішуємо це питання, починаючи спочатку з більшою сутністю, тобто країна має поля до найменш поширених чи найменших. Це добре працює для всіх країн, з якими ми експериментували досі. У нас також є розумна дублікатна система запобігання, і злиття для тих, хто так чи інакше потрапляє в систему, оскільки користувачі дуже "творчі". У розділі адміністратора у нас є порядок адресної адреси для налаштувань країни. тобто в Японії спочатку поштовий індекс (Поштовий індекс), як останній, як Великобританія / США

Загалом ми використовуємо:

• Країна
• Пошта / Поштовий індекс
• Штат / провінція / префектура / графство
• Місто / селище / село
• Вулиця / дорога / блок
• Назва / номер будівлі
• Конкретна / спеціальна інформація

Після введення та збереження може бути відображена сполучена версія, не залишаючи поля.

Як я вже говорив, це працює для всіх тих країн, у яких є програмне забезпечення, і це результат розробки з 1989 року.

Сподіваюсь, це допомагає якимось чином або хоча б дає інше розуміння.

Як уже було сказано, найбільш універсальним (але недоцільним для перевірки і, можливо, найменш корисним) є єдине велике поле унікоду.

Ви можете відокремити країну від решти адреси та зберегти її як код країни ISO. Це нормалізувало б країну і запропонувало б певну корисність для підтвердження залишку адреси.

Ви також можете відокремити поштовий індекс aka індекс від решти адреси. Це також буде корисною для перевірки залишку адреси, і може бути корисною (хоча і неточною) в геолокації. Наприклад: у Канаді ви можете однозначно ідентифікувати будь-яку адресу із зазначенням лише поштового індексу та номера вулиці (він же домашній номер); це може бути справедливим не у всіх країнах.

Виділення полів державам / провінціям або містам стає все більш проблематичним через різні способи формулювання адреси кожної країни. Я створив адресні таблиці з такими полями, тому що початкова аудиторія орієнтована на Північну Америку, знаючи, що міжнародна аудиторія створюватиме проблему з вміщенням. У більшості випадків вони можуть бути "взутими", але це незручний і потенційно схильний до невдач компроміс - безумовно, не універсальний.

Всупереч відповіді Мітчдава, я б радив не користуватися бібліотекою Google. Я шукав сховище в різних міжнародних місцях з неортодоксальними схемами адресації, сподіваючись знайти дані тестових одиниць, але тривожно знайшов нульові звернення у всьому сховищі.

Я думаю, що найкраще ставитись до адреси як до багаторядкового тексту у вільній формі. Це гарно, що ви, можливо, не можете перевірити всі адреси, але деякі формати адрес дійсно дивні та, можливо, непередбачені, і врешті-решт, заповнення правильної адреси покладається на користувача, і в більшості програм користувач несе будь-які негативні наслідки заповнення недійсна адреса.

Ви можете, можливо, використовувати валідатор для попередження , але нічого більш того. Але не відхиляйте адреси, які не підтверджують, бо в іншому випадку ви можете втратити деяких клієнтів. Це призводить до питання про те, як передавати попередження користувачеві таким чином, щоб він повідомляв, що, якщо користувач живе в районі із дивним форматом адреси, можна ігнорувати попередження ...

Як ви говорите, будь-яка адреса на землі є лише довга лат або ...

https://what3words.com

Що таке 3 слова, це алгоритм (так що не база даних не може бути вбудована в будь-що), яка може визначити 3х3 метровий патч у будь-якій точці Землі.

Тонга та декілька інших держав прийняли її як свою систему поштових індексів, хоча вона не замінить її як накладку, яка є досить класною і дуже добре побудованою та продуманою.