Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #22919 > unrolled thread

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

Back to article view | Back to it.comp.www.php

Contents

  Memorizzare nella tabella utenti solo la città o anche regione e nazione? ^Bart <gabriele1NOSPAM@hotmail.com> - 2021-07-05 20:06 +0200
    Re: Memorizzare nella tabella utenti solo la città o anche regione e nazione? bramante <bramante@yopmail.com> - 2021-07-06 00:29 +0200
      Re: Memorizzare nella tabella utenti solo la città o anche regione e nazione? ^Bart <gabriele1NOSPAM@hotmail.com> - 2021-07-06 09:04 +0200
      Re: Memorizzare nella tabella utenti solo la città o anche regione e nazione? ^Bart <gabriele1NOSPAM@hotmail.com> - 2021-07-06 09:07 +0200
        Re: Memorizzare nella tabella utenti solo la città o anche regione e nazione? bramante <bramante@yopmail.com> - 2021-07-08 23:15 +0200
          Re: Memorizzare nella tabella utenti solo la città o anche regione e nazione? ^Bart <gabriele1NOSPAM@hotmail.com> - 2021-07-10 10:46 +0200

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

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

[toc] | [next] | [standalone]

#22920

Il 05/07/21 20:06, ^Bart ha scritto:
> 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
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

[toc] | [prev] | [next] | [standalone]

#22921

> 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

[toc] | [prev] | [next] | [standalone]

#22922

> 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

[toc] | [prev] | [next] | [standalone]

#22924

Il 06/07/21 09:07, ^Bart ha scritto:
>> 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


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

[toc] | [prev] | [next] | [standalone]

#22925

> 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

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web