Operazione di login con dati memorizzati in database

4 Risposte

• M

  migliorabile

  Super Famoso

  Iscritto da

  apr, 2013

  Messaggi:

  5882

  Re: Operazione di login con dati memorizzati in database

  21 lug 2017, 19:26

  La domanda e' abbastanza confusa e dimostra la presenza di alcuni problemi di fondo:
  
  1) perche' avere tre tabelle per la gestione degli utenti di tipo A, B, C? Meglio avere una tabella U con TUTTI gli utenti ed aggiungi un attributo TIPO in cui indichi A, B, C.
  
  2)al momento l'unica soluzione e' quella di fare 3 query, una per tabella, per capire il tipo di utente
  
  3) se hai problemi con lo statement switch, stai affrontando un problema troppo complesso per le tue attuali conoscenza: inizia con esercizi piu' semplici
• 

  andbin

  Super Famoso

  Iscritto da

  ott, 2013

  Messaggi:

  6270

  Re: Operazione di login con dati memorizzati in database

  22 lug 2017, 12:36

  rossociliegia ha scritto:

  ---

  ho un database con tre tabelle, che sarebbero tre tipologie di utente, dato che ognuno fa cose diverse

  Tre tabelle per le tre tipologie di utenti, non va bene e non ha granché senso (complica parecchio la vita ...). Valuta meglio la base dati.
  
  Riguardo il fatto che "fanno cose diverse", ok ma bisogna valutare alcune cose. "Quanto" fanno cose diverse? Mi spiego meglio: nel codice avrai allora svariati punti in cui dovrai andare a verificare che se l'utente è di tipo X, allora potrà es.: vedere un pulsante/menù, vedere certi campi, ecc...
  Se hai 3 tipi, è possibile che un certo elemento/operazione sia applicabile a più/tutti i tipi? Oppure è più probabile che ciascuno elemento/operazione sia usabile da un solo tipo? Insomma, come intendi gestirlo?
  
  Oltre alla possibilità di decidere solo in base al tipo, nelle applicazioni già anche solo un pochino grandi è abbastanza frequente sfruttare il principio delle ACL (Access Control List). Ovvero nella base dati c'è una tabella che fa da "registro" dei permessi e poi c'è un'altra tabella che fa da relazione molti-a-molti tra i tipi di utente e i vari permessi ad essi assegnati. E' chiaramente più complesso da gestire ma altamente flessibile.
  Non so se è il caso tuo ... molto probabilmente no, l'ho detto giusto per completezza.
• 

  rossociliegia

  Pochi posts

  Iscritto da

  lug, 2017

  Messaggi:

  36

  Re: Operazione di login con dati memorizzati in database

  22 lug 2017, 15:41

  No non è il mio caso, l'ho voluto gestire in questo modo, cioè creare una tabella per ogni tipo di utente, perchè ogni utente ha cose diverse da fare. Altrimenti l'avrei gestita certamente con un'unica tabella. Poi ho anche poco tempo e voglio minimizzare le complicanze. Nel caso in cui dovessi incontrare difficoltà valuterò cambiamenti, per ora mi sembra una buona via.
  Comunque ho trovato il modo per controllare a chi appartengono i dati, grazie comunque ad entrambi!
• 

  andbin

  Super Famoso

  Iscritto da

  ott, 2013

  Messaggi:

  6270

  Re: Operazione di login con dati memorizzati in database

  22 lug 2017, 16:24

  rossociliegia ha scritto:

  ---

  l'ho voluto gestire in questo modo, cioè creare una tabella per ogni tipo di utente, perchè ogni utente ha cose diverse da fare.

  Non ha granché senso, come ti è stato già detto da me e @migliorabile. Discorso diverso se ciascuna tipologia di utente avesse DATI differenti. In tal caso si potrebbe fare una tabella principale Utenti in cui ci sono comunque tutti gli utenti con i dati "comuni" e poi altre tabelle es. UtentiClienti (per dire) che hanno qualcosa in più e sono in relazione uno-a-uno con la tabella principale. Questo sì è sensato e anche descritto sui libri di database design.
  

  rossociliegia ha scritto:

  ---

  voglio minimizzare le complicanze.

  Con 3 tabelle di utenti distinte, dove ciascun utente sta solo in una delle 3 tabelle, le complicazioni ... aumentano ... non diminuiscono.
  
  EDIT: ne dico giusto una, se vuoi cambiare tipo all'utente, lo devi spostare da una tabella ad un'altra. Devi fare cioè un DELETE su una e un INSERT su un'altra. E per farlo bene, dovresti farlo in maniera "transazionale", in modo che sia "atomico", perché altrimenti se il delete ha successo ma il insert fallisce, ti sei "fumato" l'utenza.
  
  Ma andiamo oltre: vuoi che altre tabelle possano referenziare un utente? E come fai verso 3 tabelle? Come metti le Foreign Key??