Kõik sõltub sellest, millisel otstarbel on plaanis neid andmeid kasutada.

Kui tegemist on taustainfoga, mille alusel ei tehta täpseid otsinguid ja mida võibolla trükitakse kirjadele/arvetele, siis piisab veerust aadress. Tõstaksin riigi "sulgude ette" nii, et tabelis on aadressiandmete jaoks kaks veergu: aadress ja riigi_kood. riigi_kood on välisvõtme veerg, mis viitab klassifikaatori tabelile Riik. Tabelis Riik olevad andmed oleksid määratud rahvusvahelise klassifikaatoriga:  https://www.iban.com/country-codes

Kui soov on teha aadressi alusel täpseid otsinguid, siis tuleb aadress "lahti lõhkuda" ning tükid erinevatesse tabelitesse/veergudesse salvestada. See pole triviaalne ülesanne. Näiteks Eestis on kasutusel kaheksa-tasemeline aadressiandmete süsteem (https://geoportaal.maaamet.ee/est/Andmed-ja-kaardid/Aadressiandmed-p112.html), mille tehnilist spetsifikatsiooni saab lugeda siit: https://geoportaal.maaamet.ee/docs/aadress/ADS_spetsifikatsioon_22_10_2012.pdf

Aadressikomponentide tasandid on seal jaotises "2.2.3.1 Aadressikomponentide tasandid".

Kuna erinevates riikides on haldusjaotuse põhimõtted erinevad, siis on seal ka aadresside komponendid erinevad. Eesti aadressiandmete süsteemi andmemudelit näete selle dokumendi https://geoportaal.maaamet.ee/docs/aadress/ADS_spetsifikatsioon_22_10_2012.pdf jaotises 2.4

O'Reilly digitaalse platvormi kaudu saab lugeda raamatut Blaha, M., 2010. Patterns of Data Modeling.
Kuidas kasutada O'Reilly digitaalset platvormi?

Peatükis 10 käsitletakse andmete modelleerimise arhetüüpe ning üks nendest on "Location" (jaotis 10.12). Eesti keele seletava sõnaraamatu kohaselt on arhetüüp "inimkonna kollektiivsest alateadvusest lähtuv püsistruktuur, mis teadvuses avaldub universaalse motiivi v. kujundina". Muinasjuttudele mõeldes on arhetüübiks näiteks noorim vend, kes lõpuks tapab lohe ning saab tasuks printsessi tähelepanu ja pool kunigriiki.

Koordinaatide hoidmisel on mõtet, kui tahate näiteks asukohti kaardil kujutada. Andmebaasis koordinaatide ja koha-aadresside hoidmine ei välista teineteist. Nii Eesti aadressiandmete süsteem kui "Location" arhetüüp näevad ette ka ruumiandmete hoidmist koordinaatidena.

Mis puudutab sobivaid veerge ja tüüpe, siis see sõltub kasutatavast koordinaatide süsteemist ja andmebaasisüsteemist.

Näide: https://twcc.fr/

PostgreSQL ja Oracle on mõlemad objekt-relatsioonilised süsteemid ning lubavad defineerida uusi tüüpe - miks mitte ka geograafiliste koordinaatide jaoks. PostgreSQLis on mõned geomeetrilised tüübid/operaatorid süsteemi-defineeritud ja ilmselt õnnestub ka neid koordinaatide esitamiseks kasutada: https://stackoverflow.com/questions/1023229/spatial-data-in-postgresql Saate esitada ruumilise asukoha Point tüüpi väärtusena.

Kui see ei sobi ning peaksin hoidma pikkus ja laiuskraade kümnendmurruna, siis kasutaksin DECIMAL(10,6) - PostgreSQL NUMBER(10,6) - Oracle. Lisaks on vaja CHECK kitsendusi. Pikkuskraad peab olema vahemikus -180 ja 180 (otspunktid kaasa arvatud) ja laiuskraad vahemikus -90 ja 90 (otspunktid kaasa arvatud).

Kui peaksin hoidma kraade, minuteid ja sekundeid, siis võtaks iga selle komponendi jaoks kasutusele täisarvu tüüpi veeru. Jällegi oleks vaja ka CHECK kitsendusi, sest näiteks 300 kraadi idapikkust ei ole õige asi.

Lugege ka: https://stackoverflow.com/questions/6665894/what-is-the-best-way-to-store-geographic-coordinate-data-in-a-database

Nii PostgreSQLi kui Oracle jaoks on olemas laiendused geograafiliste andmetega töötamiseks, kuid nendega ma kahjuks tuttav ei ole. PostgreSQL: PostGis (http://postgis.net/) Oracle: Oracle Spatial and Graph (https://docs.oracle.com/database/121/SPATL/toc.htm)