.dsy:it. - Progetto Basi 2011/2012

Pages (12): « 1 2 [3] 4 5 6 7 » ... Last »
Show 150 posts per page

.dsy:it. (http://www.dsy.it/forum/)
- Basi di dati ~ informatica triennale (http://www.dsy.it/forum/forumdisplay.php?forumid=211)
-- Progetto Basi 2011/2012 (http://www.dsy.it/forum/showthread.php?threadid=42537)

Posted by number15 on 02-01-2012 09:58:

Guarda tipo attico.it che ha tipologie/categorie. Probabilmente ti aiuta.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by SanJuanWolf89 on 02-01-2012 17:35:

Originally posted by number15
Guarda tipo attico.it che ha tipologie/categorie. Probabilmente ti aiuta.

Si ma c sono i nomi ma non caratteristiche..io nel mio progetto ho creato semplicemente una tabella categoria con attributo nome categoria con una decina d tuple..

Posted by number15 on 02-01-2012 18:14:

Ho riguardato meglio ed in effetti la prof divide diversamente rispetto al sito.

Non mi viene in mente nessuna caratteristica che avrebbe senso tabellare referita a categoria.

Dato che non è chiaro dalle specifiche io farei la divisione come attico.it usando categoria come categoria e tipologia come caratteristiche

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by SanJuanWolf89 on 02-01-2012 18:30:

Originally posted by number15
Ho riguardato meglio ed in effetti la prof divide diversamente rispetto al sito.

Non mi viene in mente nessuna caratteristica che avrebbe senso tabellare referita a categoria.

Dato che non è chiaro dalle specifiche io farei la divisione come attico.it usando categoria come categoria e tipologia come caratteristiche

Cmq ho pensato alla questione di creare una tabella solo x l'amministratore..se aggiungo una colonna a utente per identificarne il tipo vuol dire che ogni tupla di utente avra un attributo in piu..quindi in termini di spazio è molto piu pesante secondo me in quanto devo memorizzare tutti gli attributi tipo_utente invece se creo una sola tabella x l'amministratore risparmio in spazio no??

Posted by number15 on 02-01-2012 18:39:

La tua idea era di fare due tabelle identiche divise, una UTENTE e UNA ADMIN?

No, creeresti una tabella con n campi in più 'inutili'.
In ogni caso parliamo di sottigliezze, un campo in più o in meno non cambia assolutamente niente.
Il problema è che è strutturalmente sbagliato crearti due tabelle.

Tra l'altro a livello applicativo per estrarre le informazioni di un utente, non sapendo se è admin o utente normale, dovresti andarlo a cercare in due tabelle diverse?

Ragiona a livello concettuale: se i tipi di utenti fossero 4 (utente, admin, moderatore, gestore) faresti 4 tabelle?

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by SanJuanWolf89 on 03-01-2012 08:21:

Originally posted by number15
La tua idea era di fare due tabelle identiche divise, una UTENTE e UNA ADMIN?

No, creeresti una tabella con n campi in più 'inutili'.
In ogni caso parliamo di sottigliezze, un campo in più o in meno non cambia assolutamente niente.
Il problema è che è strutturalmente sbagliato crearti due tabelle.

Tra l'altro a livello applicativo per estrarre le informazioni di un utente, non sapendo se è admin o utente normale, dovresti andarlo a cercare in due tabelle diverse?

Ragiona a livello concettuale: se i tipi di utenti fossero 4 (utente, admin, moderatore, gestore) faresti 4 tabelle?

Amministratore e utente nn sn identiche, t lo scrivo in pseudocodice

table utente(
id_login, password, data registrazione, nome, cognome, email)

table amm(
id_login, password, email)

il fatto e che qnd l'amministratore vuole loggarsi l'applicazione va direttamente a cercare nella tabella amministratore (select * from amministratore) mentre se c si logga cm utente si cerca nella tabella utenti (select * from utente) mentre per l'utente non reg saremo senz'altro daccordo sul fatto che non servono credenziali.. cmq la mia idea è quella d creare due tabelle proprio per scindere i due ruoli e inoltre ora che m c hai fatto pensare si risparmi anke spazio in memoria a causa dui quell' attributo tipoUtente mentre con due tabelle non servirebbe piu..forse mi sbaglio di brutto ed e importante che c stiamo ragionando ma nn capisco proprio perchè dici che e concettualmente sbagliato creare due tabelle......se servono percjè nn crearle...

Posted by number15 on 03-01-2012 09:00:

È concettualmente sbagliato perché admin è sempre un utente.
Guardati il concetto di generalizzazione/specializzazione su slide o libro.
Puoi dividerle, ma devi tenere una stessa tabella i base. Puoi fare così se hai molti campi diversi:
UTENTE (id_utente, username, email, password, tipo_utente)
UTENTE_INFO(id_utente, nome, cognome, telefono, data_registrazione)
Dove id_utente nella seconda tabella è fk su id_utente nella prima.

Quello che vuoi far tu in fase di login non è fattibile: non sai a monte dove cercare l'utente, ma devi ogni volta cercarlo in due tabelle.
Idem per registrazione, dovrai prima cercare in entrambe le tabelle se esiste o meno un utente con quella email.

Ps: lascia perdere attualmente il discorso della memoria perché prima deve essere corretto logicamente e poi ottimizzi. Tra l'altro si potrebbe discutere se occupa di più un campo aggiuntivo in una grossa tabella rispetto ad una nuova tabella da 3 campi con molte meno righe.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by pintu on 03-01-2012 11:06:

Originally posted by number15

Quello che vuoi far tu in fase di login non è fattibile: non sai a monte dove cercare l'utente, ma devi ogni volta cercarlo in due tabelle.
Idem per registrazione, dovrai prima cercare in entrambe le tabelle se esiste o meno un utente con quella email.

Secondo me è proprio questo il fulcro della discussione (lasciando perdere costi, ottimizzazioni ecc). Avendo un unica tabella, con attributo tipoUser, quando verrà affettuato il login la SELECT verrà fatta per forza sull'unica relazione UTENTE. Penso che la imposterò cosi..

Posted by number15 on 03-01-2012 11:17:

E' sicuramente la scelta corretta.
Ti permette anche di fare cose del tipo:
if (tipo_user == 'admin')
......
else echo('non hai permessi per vedere la pagina');

Poi puoi scegliere se splittare le informazioni non comuni ad entrambe le tipologie di utente in un'altra tabella, ma dato il rapporto utenti/admin direi che un'unica tabella con alcuni valori NULL è la scelta migliore.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by SanJuanWolf89 on 03-01-2012 11:43:

mmmm..forse avete ragione..cmq provero a chiedere anche al prof cosa ne pensa..intanto provo a modificarlo cm avete detto...
un altra domanda..
x il tipo contratto ovvero affito o vendita avete creato una tabella??

Posted by pintu on 03-01-2012 11:46:

quindi secondo te è meglio cosi..

UTENTE(id_utente, username, password, tipoUtente, nome, cognome, email)

di cosi per esempio?

UTENTE(id_utente, username, password, tipoUtente)

INFO_UTENTE(id_u, nome, cognome, email, telefono)

[id_u FK on id_utente]

??

Posted by number15 on 03-01-2012 11:51:

Originally posted by SanJuanWolf89
mmmm..forse avete ragione..cmq provero a chiedere anche al prof cosa ne pensa..intanto provo a modificarlo cm avete detto...
un altra domanda..
x il tipo contratto ovvero affito o vendita avete creato una tabella??

Hai fatto lo schema ER? Queste scelte si prendono in base allo schema quando vai poi a trasformarlo in relazionale.

Ps. non sto facendo il progetto io, quindi non riesco ad essere più specifico.

Originally posted by pintu
quindi secondo te è meglio cosi..

UTENTE(id_utente, username, password, tipoUtente, nome, cognome, email)

di cosi per esempio?

UTENTE(id_utente, username, password, tipoUtente)

INFO_UTENTE(id_u, nome, cognome, email, telefono)

[id_u FK on id_utente]

??

Si, sicuramente.
Come detto il rapporto tra utenti/admin non vale la creazione di una nuova tabella.
Diciamo che su 100 utenti avrai a dir tanto 3 admin (e il rapporto sarà sempre inferiore al crescere degli utenti), quindi puoi tranquillamente mettere a NULL i campi nome, cognome, telefono agli admin (nulla comunque ti vieta di compilarli anche agli admin).

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by pintu on 03-01-2012 11:52:

@SanJuanWolf89: io ho messo l'attributo "contratto" nella tabella annuncio e ho creato la tabella CONTRATTO con due attributi...codice_contratto e tipo_contratto. Però non so mi sembra uno spreco..Alla fine i tipi di contatto sono solo affitto e vendita..Quindi magari sarebbe più sensato dare all'attributo contratto quel dominio! Io ne ho creata una a parte per la categoria

Posted by pintu on 03-01-2012 11:59:

Infatti! Anzi in qualche caso potrebbe anche essere comodo sapere nome-cognome dell'admin! Guardando il progetto come un applicazione per tutti e non solo per il buon esito dell'esame!

Posted by SanJuanWolf89 on 03-01-2012 12:04:

Originally posted by pintu
@SanJuanWolf89: io ho messo l'attributo "contratto" nella tabella annuncio e ho creato la tabella CONTRATTO con due attributi...codice_contratto e tipo_contratto. Però non so mi sembra uno spreco..Alla fine i tipi di contatto sono solo affitto e vendita..Quindi magari sarebbe più sensato dare all'attributo contratto quel dominio! Io ne ho creata una a parte per la categoria

Guarda è vero che puo sembrare uno spreco xo nella parte realtiva ai raggruppamenti se fai cm ho fatto io ovvero raggruppare x tipologia contratto e costo ti torna parecchio utile..nn saprei come farlo senza una tabella apposta quindi vada x la tabella tipocontratto

All times are GMT. The time now is 08:17.

Pages (12): « 1 2 [3] 4 5 6 7 » ... Last »
Show all 167 posts from this thread on one page