[OT] Creazione database delle città del mondo: come progettarlo?

[Shadow976]

Carissimi,
sto impostando gli elenchi geografici per un'applicazione destinata sia all'Italia che all'estero.

Le tabelle sono countries (le nazioni), states (intese come le nostre provincie, o ad esempio come i laender tedeschi o come le principali aggregazioni cittadine francesi; si chiamano states, per completezza di dati, perché negli USA corrispondono ai singoli stati), e suburbs (le cittadine intese come frazioni).

La somma di countries e states non supera le poche decine di migliaia di record; ma se dovessi impostare anche un database suburbs (ovvero frazioni e cittadine minori del mondo) dovrei scaricare fiumi di mega da un apposito sito che appesantirebbero il database enormemente per un totale di 3-4 milioni di record (paradossalmente, molto più dei record che l'utente creerebbe durante l'uso e la vita della stessa applicazione).

Sono propenso a limitarmi solo alle prime due, anche perché milioni di suburbs andrebbero aggiornati quotidinamente con una cadenza impressionante (pensate solo in Italia a quante frazioni nascono e muoiono, o cambiano nome). Perciò vi chiedo; nei gestionali più importanti, e nelle web app in generale, sono sufficienti le prime due informazioni o si preferisce spingersi anche alla terza?

Grazie a tutti,

Archimede

[Tigre851]

3 - 4 milioni di record non sono poi tantissimi se hai un buon DB configurato bene alle spalle (ad esempio un mysql con un motore veloce come MyIsam ma si può fare di meglio e qui bisognerebbe chiedere a qualche espertone di DB). Il problema potrebbero essere le operazioni di join tra tabelle (ad esempio trovare lo stato di una determinata suburbs) in questo caso ti consiglio di denormalizzare l'informazioni e creare una tabella unica con suburbs, città e stati.

[albgen]

Secondo me ti basta la nazione, regione/land/states e città.
è inutile aggiungere millioni di record per le frazioni.
Cmq dovresti chiedere agli utilizzatori dell'applicazione se servono anche le frazioni o meno.

[Shadow976]

@Tigre

Grazie inifnite per la tua risposta e per il tuo interessamento. Per diverse ragioni (programmabilità, vicinanza a Oracle, affidabilità ma soprattutto sicurezza) ho scelto PotgreSQL a mySql. Siccome:

1) Un sistema così creato mi costringerebbe ad aggiornarne quotidianamente le suburb distribuendo quantità di dati che paradossalmente sarebbero notevolmente superiori a quelli generati dalla stessa applicazione nel corso della sua vita;
2) Denormalizzare significherebbe aumentare ulteriormente le dimensioni della base dati;
3) Pur aggiornando le suburb anche ogni mese, quotidianamente sarebbero inseriti dati errati o obsoleti (pensa che i servizi che distribuiscono tali informazioni, servizi molto costosi ed altamente professionali, distribuiscono gli aggiornamenti delle suburb mondiali con cadenza impressionante, pensa su milioni di suburbs quante ogni giorno cambiano nome o sono aggregate ad altre o create);
4) Una ricerca su 3-4 milioni di record anche con il motore da te indicato impiegherebbe diversi secondi a completarsi, vista anche la join con le tabelle countries e states (a meno di non denormalizzare e trovarmi con una quantità di dati superflua e ridondante molto grande;

Ho perciò risolto come segue, e mi piacerebbe un tuo qualificato parere:

1) Ho normalizato countries e states, mettendo le loro liste in due apposite tabelle collegate con chiave numerica;
2) Nel gestionale, ho lasciato il campo suburb come semplice testo (e testo di conseguenza è rimasto anche il campo cap o meglio postcode) in modo che l'utente possa inserirci ciò che vuole;


@albgen
Albgen, è proprio quello che ho intenzione di fare, fermandomi al secondo step; quelli che sarebbero diversi milioni sono proprio le frazioni mentre invece già ora il mio sistema include le città. Per chiarezza ecco quello che intendo (nel mio db i nomi sono in inglese visto che mi hanno chiesto la massima accuratezza formale):

1) COUNTRY: nazioni. Possono essere USA, Italy, France ecc
2) STATES: stati in senso lato. Nel caso degli USA sono Alabama ecc nel caso dell'Italia sono le provincie, nel caso della Svizzera i cantoni ecc. Ovvero, come in tutti i maggiori software gestionali, corrispondono al secondo livello aggregativo geografico di una country.
3) SUBURB: Cittadine in senso stretto. Negli USA sono new york city, Springfiedl ecc, in Italia ad esempio Casal Pusterlengo, in Svizzera Berna città ecc.

[albgen]

Originariamente inviato da Shadow976
...
@albgen
Albgen, è proprio quello che ho intenzione di fare, fermandomi al secondo step; quelli che sarebbero diversi milioni sono proprio le frazioni mentre invece già ora il mio sistema include le città. Per chiarezza ecco quello che intendo (nel mio db i nomi sono in inglese visto che mi hanno chiesto la massima accuratezza formale):

1) COUNTRY: nazioni. Possono essere USA, Italy, France ecc
2) STATES: stati in senso lato. Nel caso degli USA sono Alabama ecc nel caso dell'Italia sono le provincie, nel caso della Svizzera i cantoni ecc. Ovvero, come in tutti i maggiori software gestionali, corrispondono al secondo livello aggregativo geografico di una country.
3) SUBURB: Cittadine in senso stretto. Negli USA sono new york city, Springfiedl ecc, in Italia ad esempio Casal Pusterlengo, in Svizzera Berna città ecc.

secondo me va bene cosi'. Poi ripeto la cosa giustà da fare è chiedere agli utilizzatori e sopratutto al manager del progetto elencando i pro e i contro delle due scelte.
Cmq, io ho visto software che utilizzano le frazioni e devo dire che vengono utilizzate poco o niente.

[Tigre851]

Sono d'accordo pure io, mi pare una buona soluzione :-D

[Shadow976]

Anche gli utenti sono d'accordo. Bene così, creerò liste come detto solo per i primi due livelli, countries e states, lasciando le suburb come testo liberamente inseribile dall'utente, risparmiando spazio al db di circa mille volte e risparmiandogli peraltro spazio che sarebbe abnorme rispetto alle dimensioni che avrebbe anche durante la sua vita; risparmierò anche all'utente il costosissimo servizio di abbonamento alle frazioni del mondo intero con necessità di continui aggiornamenti.

Postgre vi manda a dire che vi deve una cena, e che se non avessi fatto così mi avrebbe denunciato per maltrattamenti!

[albgen]

Originariamente inviato da Shadow976
Anche gli utenti sono d'accordo. Bene così, creerò liste come detto solo per i primi due livelli, countries e states, lasciando le suburb come testo liberamente inseribile dall'utente, risparmiando spazio al db di circa mille volte e risparmiandogli peraltro spazio che sarebbe abnorme rispetto alle dimensioni che avrebbe anche durante la sua vita; risparmierò anche all'utente il costosissimo servizio di abbonamento alle frazioni del mondo intero con necessità di continui aggiornamenti.

Postgre vi manda a dire che vi deve una cena, e che se non avessi fatto così mi avrebbe denunciato per maltrattamenti!

bene

[MacApp]

Originariamente inviato da Shadow976
Anche gli utenti sono d'accordo. Bene così, creerò liste come detto solo per i primi due livelli, countries e states, lasciando le suburb come testo liberamente inseribile dall'utente

Che alla lunga potrebbe diventare uno strumento per pubblicare qualunque cosa.