Memorizzare nella tabella utenti solo la città o anche regione e nazione?

[^Bart]

Salve,

vorrei memorizzare nella tabella utenti solo la città a cui arriverei
tramite un wizard perché ho altre tabelle che dividono continenti,
nazioni, regioni etc.

Morale della favola se ho un utente la cui città è Milano e dovessi poi
filtrare chi abita in Lombardia sarebbe un bagno di sangue di query
dover andare "all'indietro" giusto?

Meglio memorizzare anche nazione e regione oltre alla città?

Saluti.
^Bart

[bramante]

Il 05/07/21 20:06, ^Bart ha scritto:

nella tabella utenti solo
- id_user
- user
- pass
- email
- flag attivo o date di inizio / fine validità


il resto nella anagrafica

anche perchè se un utente cambia città, storicizzi la tabella anagrafica
ma non cambi la tabella utenti

[^Bart]

> nella tabella utenti solo
> - id_user
> - user
> - pass
> - email
> - flag attivo o date di inizio / fine validità
>
>
> il resto nella anagrafica
>
> anche perchè se un utente cambia città, storicizzi la tabella anagrafica
> ma non cambi la tabella utenti

Ti ringrazio per la "dritta"! :)

Saluti!
^Bart

[^Bart]

> il resto nella anagrafica
>
> anche perchè se un utente cambia città, storicizzi la tabella anagrafica
> ma non cambi la tabella utenti

Ma in un'ottica di ricerca conviene oltre alla città inserire anche,
regione, nazione, nazionalità, etc. senza dover ricavare quei dati
facendo il percorso a ritroso dalla città?

Già che si parte con un wizard imho conviene che passo passo quei dati
vengano memorizzati da qualche parte...

Saluti.
^Bart

[bramante]

Il 06/07/21 09:07, ^Bart ha scritto:

in un ottica di puro DBA i dati non devono essere MAI duplicati, devi
cercare di normalizzare il più possibile.

per farti un esempio
il dato "data nascita" deve essere presente SOLO e SOLTANTO in una tabella.
tutto il resto deve essere referenziato alla tabella che lo contiene



REGIONE
id_regione
regione
...
...

COMUNE
id_comune
Comune
sigla
cap
data_inizio
data_fine
id_regione


utente
id_user
user
pass
...
...


anagrafica_utente
id_user
nome
cognome
sesso
data_nascita
...
id_comune
id_regione (teoricamente potrebbe essere omesso, ci si arriva dal comune)
id_nazione
....

pensa a quanto è sbagliata una situazione del genere se dovessi
duplicare i dati

contratto_bolletta
id_user
nome
cognome
data_nascita
id_comune
id_regione
num_contratto


fattura_bolletta
id_bolletta
num_contratto
....
...


in questo esempio avresti i dati anagrafici (nome, cognome,
data_nascita, id_comune, id_regione) duplicati che potrebbe differire
(ad esempio se l'utente cambia la citta di residenza e aggiorni solo
l'anagrafica e non il contratto) e in una richiesta di estrazione "tutti
gli utenti residenti nel lazio che hanno un contratto" quale dato è
corretto estrarre?


tu indichi a ritroso se parti dall'utente,
select a.nome, a.cognome, a.sesso, ... b.comune, c.regione, d.nazione
from anagrafica_utente a, comune b, regione c, nazione d, user f
where a.id_comune = b.id_comune
and a.id_regione = c.id_regione
and a.id_nazione = d.id_nazione
and a.id_user = f.id_user
and f.user = "PIPPO"

ma se partissi da "estrai tutti gli utenti di milano" non è ritroso.
select a.nome, a.cognome, a.sesso, b.comune, c.regione, d.nazione,f.user
from anagrafica_utente a, comune b, regione c, nazione d, user f
where a.id_comune = b.id_comune
and a.id_regione = c.id_regione
and a.id_nazione = d.id_nazione
and a.id_user = f.id_user
and b.comune = "Milano"


se ti servisse di ricercare il numero di utenti raggruppati per comune
dell'area della lombardia, uomini con un età superiore ai 40 anni.

select count(a.id_user) as num_utenti, comune
from anagrafica_utente a, comune b, regione c
where a.id_comune = b.id_comune
and a.id_regione = c.id_regione
and TIMESTAMPDIFF(YEAR, data_nascita, NOW()) > 40
and sesso = 'M'
group by comune


non esiste il concetto di ricerca al ritroso, esiste il concetto di
estrazione di dati o aggregati.


un ultimo consiglio
inserisci sempre i riferimenti agli "id" e mai alla descrizione
come ho fatto nei miei esempi ho sempre indicato id_comune o id_regione,
MAI la descrizione della stessa.

questo perchè la descrizione è soggetta a cambiamenti.

https://it.wikipedia.org/wiki/Modifiche_territoriali_e_amministrative_dei_comuni_d%27Italia

[^Bart]

> in un ottica di puro DBA i dati non devono essere MAI duplicati, devi
> cercare di normalizzare il più possibile.

Giusto.

> per farti un esempio
> il dato "data nascita" deve essere presente SOLO e SOLTANTO in una tabella.
> tutto il resto deve essere referenziato alla tabella che lo contiene

Ok.
>
> utente
> id_user
> user
> pass

Corretta l'idea di tenere una tabella solo per le credenziali di login.

> anagrafica_utente
> id_user
> nome
> cognome
> sesso
> data_nascita
> ...
> id_comune
> id_regione (teoricamente potrebbe essere omesso, ci si arriva dal comune)
> id_nazione

Per ora ho lasciato nazione, regione, provincia e città.

> pensa a quanto è sbagliata una situazione del genere se dovessi
> duplicare i dati
>
> contratto_bolletta
> id_user
> nome
> cognome
> data_nascita
> id_comune
> id_regione
> num_contratto
>
>
> fattura_bolletta
> id_bolletta
> num_contratto

Chiarissimo!

> non esiste il concetto di ricerca al ritroso, esiste il concetto di
> estrazione di dati o aggregati.

Mi sono espresso male! :)

> un ultimo consiglio
> inserisci sempre i riferimenti agli "id" e mai alla descrizione
> come ho fatto nei miei esempi ho sempre indicato id_comune o id_regione,
> MAI la descrizione della stessa.

Hai fatto bene a precisarlo, in questo caso però ero cosciente del tutto! :)

Grazie per tutte le info! :)

Saluti.
^Bart