 | |
Il progetto dsy.it è l'unofficial support site dei corsi di laurea del Dipartimento di Scienze dell'Informazione e del Dipartimento di Informatica e Comunicazione della Statale di Milano. E' un servizio degli studenti per gli studenti, curato in modo no-profit da un gruppo di essi. I nostri servizi comprendono aree di discussione per ogni Corso di Laurea, un'area download per lo scambio file, una raccolta di link e un motore di ricerca, il supporto agli studenti lavoratori, il forum hosting per Professori e studenti, i blog, e molto altro...
In questa sezione è indicizzato in textonly il contenuto del nostro forum |
Social network 2010/2011
Clicca QUI per vedere il messaggio nel forum |
| zandrek |
ciao una domand,io ho già creato il db e inserito qualche decina di giochi e utenti ma non mi è chiara una cosa : i vari permessi degli utenti (vedere profilo degli amici, vedere le classifiche) o piuttosto il non vedere le statistiche (che vede solo analista e admin) lo devo fare nella costruzione del db o fa tutto php? qualcuno nel caso mi indica qualche tutorial/guida di php e postgres?
grazie
EDIT
il fatto che un utente non possa scrivere cavolate tipo mettere che il proprio nome è "via golgi" lo faccio dal db o sempre con php? |
| CowBoy |
Se hai già definito i permessi degli utenti del DBMS sulle tabelle, allora ti spiego come avevo risolto io:
1- Definisco sul DBMS un ruolo(utente del DBMS) per ciascuna tipo utente del sistema(login, admin, user, analyser, ecc)
2- Effettuo il login con una connessione tramite php al mio DBMS con utente del DBMS senza permessi per fare altro(ruolo di utenza "login")
, cioè solo un GRANT SELECT sulla tabella con le info di login utente di sistema
3- Dopo di che, per ogni tipo di utente del sistema che desidera consultare il DBMS, creo una connessione diversa tramite php in base al ruolo assegnatoli: admin, user, analyser, ect...
Il punto due si può modificare in base a come hai scelto la/e tabelle di login... se hai più tabelle, una per ogni ruolo, allora scegli subito la connessione adeguata senza dover creare un ruolo di tipo "login"...
P.S: Vedere il profilo o le classifiche di amici non dipende dal ruolo utente, bensì dalla funzione postgres che andrà a fare i controlli vari e dai GRANT che hai dato alla tabelle per il ruolo "user"
Di non vedere le statistiche invece sì.
Se non ho chiarito bene i tuoi dubbi chiedi pure...
Ciao! |
| CowBoy |
EDIT
il fatto che un utente non possa scrivere cavolate tipo mettere che il proprio nome è "via golgi" lo faccio dal db o sempre con php? [/B]
Non conosco le specifiche di questo progetto, penso che vada controllato l'input in fase iniziale, quindi con php, per poi passarlo al DB. |
| CowBoy |
| FATE MOLTA ATTENZIONE - Le tabelle devono avere i permessi necessari per i ruoli definiti in modo da poter eseguire le funzioni su di esse; l'idea è di far sì che le funzioni che andrai ad utilizzare trovino/scrivano/aggiornino/eliminino tutte le informazioni di cui hanno bisogno. |
| zandrek |
Non conosco le specifiche di questo progetto, penso che vada controllato l'input in fase iniziale, quindi con php, per poi passarlo al DB.
si hai ragione che domanda idiota...poi comunque se uno inserisce dati alla c***o oltre un certo limite non è un mio problema.
....e dai GRANT che hai dato alla tabelle per il ruolo "user" Di non vedere le statistiche invece sì.
questo me lo hai chiarito benissimo grazie!!!!
3- Dopo di che, per ogni tipo di utente del sistema che desidera consultare il DBMS, creo una connessione diversa tramite php in base al ruolo assegnatoli: admin, user, analyser, ect...
idem come sopra, finalmente vedo tutto meno fumoso, grazie ancora!
ma sei del terzo anno tu o hai già finito tutto? ciao e buona domenica |
| CowBoy |
| Sono fuori corso ormai e mi manca lo scritto di basi, reti ed algoritmi... in bocca al lupo e buona domenica anche a te! |
| pirlo21 |
io ho un dubbio sulla gestione delle tipologie...
voi avete creato una sola tabella con un campo che definisce la tipologia (carte, videogioco, da tavola) oppure n tabelle diverse in base al numero di tipologie?
Nel primo caso ci sarebbe l'inconveniente di avere molti campi con valori opzionali e quindi occorre inserire dei controlli per assicurarsi che in base alla tipologia vengano inseriti determinati valori e non altri (ad esempio in gioco di carte non posso inserire piattaforma di videogioco).
Inoltre l'inserimento di nuovi utenti lo avete reso possibile oppure resteranno solo quelli inseriti da noi programmatori? |
| Chobeat |
| beh un form piccolo piccolo di registrazione dovrebbe esserci. Cioè non è che ci voglia molto a farlo... |
| kermit63 |
non ho ben capito in che modo vadano usati i TAG, sono indeciso tra tre possibilita':
1) l'utente puo' inventarsi e inserire nuovi TAG ad un gioco.
2) l'utente prende un TAG tra quelli disponibili e lo attribuisce a un gioco.
3) non ho capito nulla
cmq pensavo di usare semplicemente una tabella gioco-TAG |
| Snakethesniper |
Originally posted by kermit63
non ho ben capito in che modo vadano usati i TAG, sono indeciso tra tre possibilita':
1) l'utente puo' inventarsi e inserire nuovi TAG ad un gioco.
2) l'utente prende un TAG tra quelli disponibili e lo attribuisce a un gioco.
3) non ho capito nulla
cmq pensavo di usare semplicemente una tabella gioco-TAG
Premetto che il progetto comincerò a farlo più avanti, ho comunque dato un'occhiata al testo ecc.
Anche io pensavo di usare una tabella TAG in quanto come si evince dalla traccia, TAG sarebbe un attributo multivalore e di conseguenza viene gestito come una tabella, seguendo l'ottimizzazione degli attributi (1,n). Io pensavo cmq di usare un dominio predefinito per il TAG che l'utente può scegliere. |
| Snakethesniper |
Originally posted by Snakethesniper
Premetto che il progetto comincerò a farlo più avanti, ho comunque dato un'occhiata al testo ecc.
Anche io pensavo di usare una tabella TAG in quanto come si evince dalla traccia, TAG sarebbe un attributo multivalore e di conseguenza viene gestito come una tabella, seguendo l'ottimizzazione degli attributi (1,n). Io pensavo cmq di usare un dominio predefinito per il TAG che l'utente può scegliere.
Mi son spiegato male alla fine, creare un dominio con valori predefiniti (avventura,azione,strategia ecc.) che l'utente può scegliere. |
| pirlo21 |
io sono d'accordo sulla tabella tag-gioco...
per quanto riguarda il dominio invece non vorrei che ti confondi con la tipologia...
io come tag intendo qualsiasi parola che mi viene in mente pensando al gioco, quindi di libera scelta dell'utente...
Piuttosto io sono molto indeciso sulle tipologie, perchè sono predefinite da noi progettisti, quindi ad esempio:
videogioco, gioco da tavola, gioco di carte
però videogioco a sua volta deve contenere il tipo di console che è multivalore (un gioco può uscire per xbox e wii ad esempio)
quindi come pensate di legare gioco a tipologia? |
| number15 |
Ho dato un'occhiata molto veloce al primo paragrafo (non devo dare l'esame) però provo a darvi una mano.
Vi scrivo il relazionale.
GIOCO(id_gioco, nome_gioco, tipologia, età, numero_giocatori_richiesto) /* tipologia campo enum(videogioco, gioco da tavola, gioco di carte) */
TAG(id_tag, nome_tag) /* tag per i giochi */
GIOCO_TAG(id_gioco, id_tag)
PIATTAFORMA(id_piattaforma, piattaforma) /* es xbox, wii, ps3*/
PIATTAFORMA_VIDEOGIOCO(id_piattaforma, id_gioco)
GIOCO_DA_TAVOLA(id_gioco, numero_giocatori_suggerito, durata_prevista) /* info aggiuntive sui giochi da tavola; si può anche mettere tutto in gioco, 'accettand' di aver valori null per questi campi nei videogiochi e nei giochi di carte */ |
| pirlo21 |
pensavo anche io a una cosa del genere....però bisognerebbe implementare per forza in php i controlli del tipo "se è un videogioco deve avere per forza almeno una console di riferimento"
oppure "se è un gioco da tavola può avere un numero di giocatori suggerito"..............
non c'è un implementazione più efficace per far sì che tutto sia gestito a livello dbms? |
| number15 |
Direi di no.
Per risolvere quelle richieste ti basta fare 3 form, una per ogni tipologia, dove per videogiochi metti obbligatorio il campo console, mentre in quella giochi da tavolo metti facoltativo il campo nr. giocatori.
Poi vai a fare le insert nelle rispettive tabelle. |
| michele.c |
Scusate, vorrei sottoporre un quesito che forse mi sono posto solo io.
Non trovate problematica la gestione dell'utente Amministratore?
Dalle specifiche del progetto si evince che:
1) l'amministratore è l'unico che "può agire come qualsiasi altro utente dell'applicazione"
2) quindi si suppone che i normali Iscritti non possono essere anche Analisti, e viceversa.
Se organizzassimo Utente in una gerarchia, avremmo che:
- per rispettare la condizione 1, dovremmo avere una gerarchia Overlapping (sovrapposta)
- per rispettare la condizione 2, dovremmo avere una gerarchia Esclusiva tra Iscritto e Analista
Tutto ciò porta ad un insieme vuoto.
Come organizzare quindi una gerachia Utente tra le sottoclassi Admin, Iscritto e Analista? |
| number15 |
Direi semplice campo enum (normale, analista, admin) in utente.
Ho capito quello intendi tu, cioè che un admin è anche un utente normale, ma nella tabella tu avrai 1 riga per ogni utente quindi è TE.
Poi a livello di programmazione farai una cosa del tipo:
se utente è admin o normale
...
se utente è analista
....
se utente è admin
... |
| michele.c |
Io ho capito che Admin è sia utente Iscritto che utente Analista. Giusto?
Per campo enum cosa intendi? A livello di schema ER a cosa corrisponde? a un attributo su Utente? |
| number15 |
Ci sta che admin sia anche analista, solitamente admin 'è tutto'.
Le specifiche su ste cose sono un po' vaghe, sta a te scegliere.
Se dovessi farlo io il progetto, ad admin darei tutti i permessi.
ENUM è un tipo di dato.
A livello ER direi che devi disegnare un'entità UTENTE e collegarci le 3 entità specializzate NORMALE, ANALISTA, ADMIN tutte con cardinalità 0,1.
Diventa un attributo su utente nel passaggio successivo, da ER --> a relazionale. |
| michele.c |
| Ma come si fa a dire, in una gerarchia T,E che Admin è un amministratore, ma fa anche l'iscritto e l'analista? |
| kermit63 |
dunque, il testo dice che le statitiche per gli analisti devono essere materializzate (immagino tabelle e non viste). ma cosa conviene quindi fare?
tabella REPORT dei giochi (o attributi in GIOCO), con ID gioco come pk e attributi percentuali di proprietari, media voti ecc
tabella PROFILO degli utenti (o attributi in UTENTE) con ID utente come pk e numero di giochi posseduti, provati, votati ecc.
in questo caso ogni aggiornamento/cancellazione di una comporterebbe il far aggiornare entrambe le tabelle (impiegandoci troppo ovviamente).
Quale soluzione quindi? |
| number15 |
Originally posted by michele.c
Ma come si fa a dire, in una gerarchia T,E che Admin è un amministratore, ma fa anche l'iscritto e l'analista?
Non si fa. Da un punto di vista ER son entità divise.
L'admin non è un utente normale nè un analista, ma ha pure i loro permessi.
Io la vedo così.
Tra l'altro qua mi pare facile, visto che non ci sono attributi diversi a seconda della tipologia di utente. |
| offear |
Ciao,
il progetto può essere creato con gli strumenti che si preferisce o esistono dei vincoli?
Si può usare Microsoft SQL?
Grazie:D |
| michele.c |
Originally posted by number15
Non si fa. Da un punto di vista ER son entità divise.
L'admin non è un utente normale nè un analista, ma ha pure i loro permessi.
Io la vedo così.
Tra l'altro qua mi pare facile, visto che non ci sono attributi diversi a seconda della tipologia di utente.
Già. Perchè a livello di ER secondo me non si può dire che amministratore faccia sia iscritto che analista, e contemporaneamente iscritto e analista sono insiemi disgiunti.
Grazie. |
| michele.c |
Originally posted by offear
Ciao,
il progetto può essere creato con gli strumenti che si preferisce o esistono dei vincoli?
Si può usare Microsoft SQL?
Grazie:D
Non ci sono vincoli sugli strumenti, per quanto ricordi.
Tutti i vincoli sono presenti sulle sul testo del progetto! Se non c'è scritto nulla puoi usare quello che vuoi |
| offear |
Originally posted by michele.c
Non ci sono vincoli sugli strumenti, per quanto ricordi.
Tutti i vincoli sono presenti sulle sul testo del progetto! Se non c'è scritto nulla puoi usare quello che vuoi
k grazie, ma cmq credo che userò postgre alla fine...secondo voi riesco a preparare lo scritto per l'appello di febbraio?
:D |
| asgar |
| scusate la domanda niubba, ma alla fine quando avrò più utenti registrati la tabella pg_user rimane sempre con admin, utente_normale e utente_analista o oltre a questi vengono memorizzati anche tutti gli altri utenti quindi avrò chessò franco, giacomo, luca ecc..? |
| Spedom |
Ciao a tutti,
cito testualmente dal punto 2 delle specifiche:
"Tutte le funzioni di statistica per l'utente analista sono materializzate............Il profilo di ogni utente, comprensivo della lista di amici e dei giochi posseduti e/o votati è realizzata tramite viste"
non capisco se l'ultimo capoverso è relativo alle sole funzioni dell'analista o quando un utente accede occorre creare una vista materializzata con i suoi dati! Come lo avete interpretato/implementato?
Grazie. |
| gek |
Originally posted by Spedom
Ciao a tutti,
cito testualmente dal punto 2 delle specifiche:
"Tutte le funzioni di statistica per l'utente analista sono materializzate............Il profilo di ogni utente, comprensivo della lista di amici e dei giochi posseduti e/o votati è realizzata tramite viste"
non capisco se l'ultimo capoverso è relativo alle sole funzioni dell'analista o quando un utente accede occorre creare una vista materializzata con i suoi dati! Come lo avete interpretato/implementato?
Grazie.
Per il momento ho creato 2 viste: una per il profilo utente e raccoglie alcuni dati come n° giochi posseduti o provati, n° di amici, media votazioni,ecc..; l'altra come statistica dei giochi contenente dati sui giochi, sono però delle viste 'totali' riferite cioè a tutti i giochi e a tutti gli utenti, non penso sia una buona scelta creare una vista per ogni utente...a meno che le viste non vengano cancellate... |
| Spedom |
Originally posted by gek
Per il momento ho creato 2 viste: una per il profilo utente e raccoglie alcuni dati come n° giochi posseduti o provati, n° di amici, media votazioni,ecc..; l'altra come statistica dei giochi contenente dati sui giochi, sono però delle viste 'totali' riferite cioè a tutti i giochi e a tutti gli utenti, non penso sia una buona scelta creare una vista per ogni utente...a meno che le viste non vengano cancellate...
Grazie per la tua risposta.
Concordo con te circa la pessima idea di una vista per ogni utente....era il motivo per il quale cerco conforto......spero in qualche altro suggerimento e/o interpretazione delle specifiche.
Saluti. |
| manux7 |
| Dopo l'appello di febbraio, il progetto sarà sempre questo o cambierà? |
| CowBoy |
| Sarà sempre questo. |
| Snakethesniper |
Premetto che mi sto rimettendo adesso a guardare il progetto, quindi probabilmente sono un po' arrugginito, volevo un parere.
Nel progetto c'è scritto che bisogna avere due liste (giochi provati/posseduti e giochi desiderati) e che per la lista di giochi posseduti l'utente può inserire un voto e una recensione. Ecco, le liste in questo caso vanno gestite come tabelle giusto? Perchè io stavo pensando di fare due tabelle:
- Giochi posseduti : Recensione,Titolo_Gioco(che si collega poi al Titolo dell'entità gioco),Voto.
- Giochi Desiderati: Titolo_Gioco ..ed eventualmente altre cose se mi vengono in mente..
che dite è corretto? |
| Chobeat |
| La soluzione più ovvia è in realtà avere una sola tabella con un flag che è true se sono posseduti e false se sono provati, o eventualmente più flag se vuoi implementare più stati come avevamo fatto noi. |
| Snakethesniper |
Originally posted by Chobeat
La soluzione più ovvia è in realtà avere una sola tabella con un flag che è true se sono posseduti e false se sono provati, o eventualmente più flag se vuoi implementare più stati come avevamo fatto noi.
si mi sembra anche questa una buona soluzione, c'è da dire però che appunto oltre a quelli posseduti/provati c'è da fare un elenco di quelli desiderati, certo anche questo si potrebbe implementare con i flag |
| number15 |
| Se l'intersezione dei 3 stati è insieme vuoto, puoi anche fare un unico campo enum(provato, desiderato, posseduto) |
| Snakethesniper |
| Ho un altro dubbio, la tipologia voi come la state gestendo? Io pensavo di fare un tipo di entità per ogni tipo con i propri attributi... |
| asgar |
forse qualcuno ha avuto il mio stesso problema:
accedo con una query php al mio database su postgres: ho una tabella test sul database social, ho un utente testrole sul quale faccio questa grant:
GRANT SELECT ON social.test TO testrole;
la grant va a buon fine e fin qui tutto ok;
da php ho la mia connessione al db:
function test_connection_pgsql() {
$connection = "host=localhost dbname=social user=testrole password=miapwd";
return pg_connect ($connection);
}
e faccio la query in questo modo:
if ($db = test_connection_pgsql()) {
print 'Connessione al DBMS riuscita.<br />';
$sql = "SELECT * FROM social.test";
$resource = pg_query($db, $sql);
$row = pg_fetch_array($resource,NULL,PGSQL_ASSOC);
print_r ($row);
pg_free_result($resource);
pg_close($db);
}
la cosa strana è che la connessione va a buon fine, infatti ottengo:
"Connessione al DBMS riuscita."
però a seguire mi dice che l'utente non ha il permesso di select sulla tabella(anche se l'ho precedentemente grantato):
Warning: pg_query(): Query failed: ERROR: permission denied for schema social LINE 1: SELECT * FROM social.test ^
dove sbaglio?
ubuntu 10.10
postgresql 8.4
php 5 |
| Stefano2912 |
| Guarda io non ho creato gruppi utenti e permessi (non erq richiesto) e ho preso +3.. Non stare a complicarti la vita.. :D |
| asgar |
Originally posted by Stefano2912
Guarda io non ho creato gruppi utenti e permessi (non erq richiesto) e ho preso +3.. Non stare a complicarti la vita.. :D
cioè ti connettevi sempre col tuo utente postgres? |
| Stefano2912 |
| Si. Tanto era in localhost :D |
| asgar |
| ottimo allora.. mi risparmio di salvare il tipo utente nella sessione e di controllarlo :) |
| Chobeat |
| idem, anche noi +3. se fai bene il resto, quello non serve. |
| Snakethesniper |
Qualcuno sa darmi una mano riguardo la tipologia? Sto cercando di capire come implementarla nello schema ER. Cioè in linea di massima ho già trovato come metterle, il problema mi viene quando penso poi alla realizzazione, in particolare se viene eseguita una query che richiede le informazioni di un gioco e bisogna segnalarne la tipologia.
Una soluzione sarebbe quella di inserire un attributo "tipo" in gioco che si collegherà all'attributo "nome_tipo" in tipologia dove ci saranno tutti gli attributi delle varie tipologie con cardinalità (0,1). Però questa non mi sembra la soluzione ideale, più che altro perchè penso che in una query come quella descritta sopra poi compaiano campi vuoti con gli attributi che non c'entrano niente con la tipologia selezionata, io preferivo avere una cosa più "pulita" e avere solo gli attributi di quel determinato tipo.
L'altra soluzione era appunto tenere sotto le sottoclassi di tipologia e quindi avere 3 entità : videogioco, giochi da tavolo, giochi di carte. Il problema però sarebbe poi visualizzare in una query il nome del tipo, per il semplice fatto che mi sembra stupido inserire in queste entità un attributo "nome_tipo" che si ripete per ogni tipo di entità (ovvero in Videogioco, nome_tipo sarà sempre videogioco ecc.).
Qualcuno può aiutarmi a chiarirmi le idee? Anche perchè ho la sensazione che sto facendo parecchia confusione xD |
| Snakethesniper |
Per dare un'idea di quello che ho scritto sopra, copio qui lo schema logico di un esercitazione presente sul sito:
Proprietario (codice, telefono, indirizzo)
• PersonaFisica (codice, CF, nome, cognome)
• PersonaGiuridica(codice, PI, denominazione)
Con codice in Proprietario come chiave primaria e Codice in PersonaFisica e PersonaGiuridica come chiave primaria e chiave esterna.
Ora, se volessi fare una query che, dato un codice di un proprietario mi venga segnalato se è una persona fisica o una giuridica come potrei fare? |
| zandrek |
Non ho letto i tuoi messaggi precedenti comunque con questa query trovi i nomi dei proprietarifisici
SELECT nome
FROM Proprietario, PersonaFisica
WHERE Proprietario.codice = PersonaFisica.codice
ovviamente se tu inserissi sta roba in un db o in un progetto potresti fare una funzione che se la query precedente non torna nulla allora sul "sito" fai comparire qualche avviso o roba simile... |
| number15 |
Originally posted by Snakethesniper
Per dare un'idea di quello che ho scritto sopra, copio qui lo schema logico di un esercitazione presente sul sito:
Proprietario (codice, telefono, indirizzo)
• PersonaFisica (codice, CF, nome, cognome)
• PersonaGiuridica(codice, PI, denominazione)
Con codice in Proprietario come chiave primaria e Codice in PersonaFisica e PersonaGiuridica come chiave primaria e chiave esterna.
Ora, se volessi fare una query che, dato un codice di un proprietario mi venga segnalato se è una persona fisica o una giuridica come potrei fare?
Non sto capendo il tuo problema.
Quell'implementazione dell'esempio è fatto ad minchiam.
Aggiungi nella tabella proprietario un campo tipo, che realizzi con un enum(persona fisica, persona giuridica, entrambi) (nomi decenti e, se esclusiva, 'entrambi' va via).
A quel punto hai l'informazione che ti serve nella tabella, senza if, join e robe strane. |
| Snakethesniper |
Originally posted by number15
Non sto capendo il tuo problema.
Quell'implementazione dell'esempio è fatto ad minchiam.
Aggiungi nella tabella proprietario un campo tipo, che realizzi con un enum(persona fisica, persona giuridica, entrambi) (nomi decenti e, se esclusiva, 'entrambi' va via).
A quel punto hai l'informazione che ti serve nella tabella, senza if, join e robe strane.
Si ci avevo pensato infatti. Allora da questo una domanda, se io nel progetto creo 3 entità per le 3 tipologie di giochi (collegate all'entità Gioco tramite l'id_gioco per esempio) e metto all'entità gioco il campo Tipo, se dovessi fare una query che dato il nome di un gioco ne richiede tutte le informazioni, dovrei fare un'inner join con tutte e 3 le entità giusto? E in tal caso è considerata una cosa fattibile oppure troppo incasinata? Dico a livello di analisi del progetto da parte del professore |
| Snakethesniper |
Uhm forse ho detto una mezza cavolata...
In pratica, quello che vorrei realizzare è fare in modo che se viene fatta una query su un gioco vengano visualizzate tutte le informazioni relative, quindi per esempio se è un videogioco voglio che vengano visualizzate solo le informazioni relative a quella tipologia e non anche quelle delle altre. Per questo motivo volevo un campo che specificasse la tipologia in modo che poi venivano visualizzate solo gli attributi di quella determinata tipologia e non quelli delle altre... Non so se si capisce cosa intendo |
| number15 |
Allora, da quanto ho capito tu avrai una tabella GIOCO che si specializza in 3 tabelle, una per ogni tipologia di gioco, con una gerarchia, immagino, di tipo totale esclusivo.
A quel punto, una volta che tu hai l'id, fai la join tra gioco e la tabella specializzata che ti interessa in base al tipo del gioco. |
| Snakethesniper |
Originally posted by number15
Allora, da quanto ho capito tu avrai una tabella GIOCO che si specializza in 3 tabelle, una per ogni tipologia di gioco, con una gerarchia, immagino, di tipo totale esclusivo.
A quel punto, una volta che tu hai l'id, fai la join tra gioco e la tabella specializzata che ti interessa in base al tipo del gioco.
ecco, esattamente! Ma si può fare? Premetto che php non l'ho ancora guardato e l'esame l'ho fatto a gennaio quindi sono un po' arrugginito a riguardo, ma è possibile fare un confronto tra il valore di un attributo e il nome di un'entità? |
| number15 |
| edit: esempio del cazzo, penso a qualcosa di meglio |
| number15 |
Abbiamo questa situazione:
gioco(id_gioco, gioco, tipo, genere)
videogioco(id_gioco, console, v.m.)
gioco_di_società(id_gioco, durata, nr._giocatori_minimo)
Vuoi stampre una tabella con l'elenco dei giochi generale.
-Esegui questa query:
(select id_gioco,gioco, tipo, genere from gioco)
-crei una tabella con 3 campi: icona tipologia del gioco (basata sul valore del campo tipo), nome del gioco, genere.
-al click sul nome del gioco, vuoi mostrare le informazioni aggiuntive del gioco.
Facciamo che hai cliccato su Nba2k11:
if tipo = videogioco
select console, vm
from videogioco
where id_gioco = '$id_gioco'
-stampi i valori dei campi
Questa è proprio un'applicazione base.
Un altro esempio, per cui ti è fondamentale il campo tipo, è:
'Mostrami i nomi di tutti i videogiochi".
Ti basta fare:
select gioco
from gioco
where tipo ='videogioco' |
| Snakethesniper |
Originally posted by number15
Abbiamo questa situazione:
gioco(id_gioco, gioco, tipo, genere)
videogioco(id_gioco, console, v.m.)
gioco_di_società(id_gioco, durata, nr._giocatori_minimo)
Vuoi stampre una tabella con l'elenco dei giochi generale.
-Esegui questa query:
(select id_gioco,gioco, tipo, genere from gioco)
-crei una tabella con 3 campi: icona tipologia del gioco (basata sul valore del campo tipo), nome del gioco, genere.
-al click sul nome del gioco, vuoi mostrare le informazioni aggiuntive del gioco.
Facciamo che hai cliccato su Nba2k11:
if tipo = videogioco
select console, vm
from videogioco
where id_gioco = '$id_gioco'
-stampi i valori dei campi
Questa è proprio un'applicazione base.
Un altro esempio, per cui ti è fondamentale il campo tipo, è:
'Mostrami i nomi di tutti i videogiochi".
Ti basta fare:
select gioco
from gioco
where tipo ='videogioco'
ok finalmente mi sono schiarito le idee, grazie!
un'ultima puntualizzazione, nello schema ER basta che semplicemente credo una associazione tra Gioco e le varie tipologie giusto? Tipo:
Gioco <-- --> Videogioco
Gioco <-- --> Gioco da tavola
Gioco <-- --> Gioco di carte |
| number15 |
Si, e indichi la cardinalità.
La parte delle generalizzazioni/specializzazioni mi ricordo che è fatta molto bene sulle slide della prof.
C'è sia come rappresentarle nel diagramma ER sia come passarle in relazionale. |
| Snakethesniper |
Originally posted by number15
Si, e indichi la cardinalità.
La parte delle generalizzazioni/specializzazioni mi ricordo che è fatta molto bene sulle slide della prof.
C'è sia come rappresentarle nel diagramma ER sia come passarle in relazionale.
sisi, quelle me le ricordo, era appunto per avere una conferma. Ti rigrazio moltissimo, sei stato di grande aiuto :-D |
| blue_tech |
Dunque sto iniziando ora a preparare il progetto ma non mi son chiare varie cose... Primo il discorso delle viste:
dice che il profilo con amici e giochi deve essere fatto tramite viste materializzate. Ora qui nasce il primo problema.
1) come materializzo effettivamente le viste? cioè se faccio una create view creo la vista ok ma come la materializzo?
2) anche le statistiche vanno fatte con viste materializzate e qui il problema al punto 3
3) tutto va tenuto aggiornato con i trigger quindi dovrei aggiornare le viste che però vengono fatte su più tabelle e quindi praticamente è infattibile perchè un aggiornamento è fattibile su viste fatte su una sola tabella
Chi mi chiarisce un pò sto discorso delle viste?
EDIT: tolto il PS avevo sbagliato a digitare un nome nel comando :P
Grazie a chi mi schiarirà un pò le idee... |
| Snakethesniper |
Una delucidazione sui giochi degli utenti.
Visto che il risultato finale che devo ottenere è un'entità "Giochi_Utente" con attributi ID_Gioco,ID_Utente, Tipo,Voto*,Recensione* (o almeno io l'ho pensata così, ovvero tenendo la superclasse e mettendo l'attributo Tipo), nello schema ER posso creare un'associazione chiamata appunto "giochi utente" con i suoi 3 attributi che collega le entità gioco e utente? In questo modo poi con il passaggio a schema logico verrà fuori la relazione/entità decisa prima no? |
| number15 |
In serata ti rispondo per bene.
Comunque leggendo veloce direi che nell'er devi creare solo un 'rombo' tra utente e gioco.
Poi in relazionale si creerà utente_gioco.
L'attributo tipo va solo in gioco, non te lo porti dietro. |
| Snakethesniper |
Originally posted by number15
In serata ti rispondo per bene.
Comunque leggendo veloce direi che nell'er devi creare solo un 'rombo' tra utente e gioco.
Poi in relazionale si creerà utente_gioco.
L'attributo tipo va solo in gioco, non te lo porti dietro.
si, parlavo proprio del "rombo". L'attributo tipo serve per indicare se è posseduto/provato oppure desiderato, quindi penso debba rientrare nell'entità Gioco_Utente |
| number15 |
Ah ops, pensavo tipo di gioco. ;)
Allora direi tutto giusto |
| Snakethesniper |
| Un'altra cosa, che sto andando in confusione, riguarda sempre i tipi di gioco. Io nello schema avevo fatto appunto Gioco e sotto le sottoclassi Videogioco, gioco di carte, gioco da tavolo. Ho deciso di tenere sia superclasse che sottoclasse, di conseguenza ho creato le associazioni 1:1 tra la superclasse e le sottoclassi. Ora il mio dubbio è, so che in questo caso bisogna per forza farle 1:1, ma è corretto in questo caso? Nel senso, per esempio, Videogioco non dovrebbe avere cardinalità 1,n con gioco? |
| number15 |
La cardinalità è 0,1 (un gioco può essere 1 videogioco O un gioco di carte O un gioco da tavolo).
Facciamo che id_gioco = 1 sia nba 2k11.
Ad nba2k11 corrisponderà 1 e una sola tupla in videogioco e l'id_gioco = 1 in videogioco corrisponderà esclusivamente ad nba2k11.
Quindi ricapitolando avrai:
gioco (0,1) videogioco
videogioco (1,1) gioco |
| Snakethesniper |
Originally posted by number15
La cardinalità è 0,1 (un gioco può essere 1 videogioco O un gioco di carte O un gioco da tavolo).
Facciamo che id_gioco = 1 sia nba 2k11.
Ad nba2k11 corrisponderà 1 e una sola tupla in videogioco e l'id_gioco = 1 in videogioco corrisponderà esclusivamente ad nba2k11.
Quindi ricapitolando avrai:
gioco (0,1) videogioco
videogioco (1,1) gioco
Edit: non riesco a capire bene una cosa, perchè 1,1? nel senso, ad una tipologia non possono far parte più giochi? In questo caso quindi non ci dovrebbe essere N ? |
| gab217 |
| Ciao a tutti volevo chiedervi voi cosa intendete e come trovate il valore numerico il valore numerico proporzionale alla similarità tra utenti? |
| Snakethesniper |
Originally posted by gab217
Ciao a tutti volevo chiedervi voi cosa intendete e come trovate il valore numerico il valore numerico proporzionale alla similarità tra utenti?
Se non erro sul testo parlava di numero dei giochi posseduti/provati che si hanno in comune, ma potrei sbagliarmi, al momento non ho il testo sotto mano.
Avrei invece una domanda sulla questione amicizie, io ho fatto un'associazione ricorsiva in Utente visto che appunto l'amicizia è tra due entità di tipo utente, dite che è corretto? |
| gab217 |
allora nessun numero?
Per quanto riguarda l'amicizia ankio ho ragionato nel tuo stesso modo quindi mi sembra corretto.
Come hai gestito invece dove chiedeva di realizzare tramite viste il profilo comprensivo di amici e di giochi posseduti/votati? |
| Snakethesniper |
Originally posted by gab217
allora nessun numero?
Per quanto riguarda l'amicizia ankio ho ragionato nel tuo stesso modo quindi mi sembra corretto.
Come hai gestito invece dove chiedeva di realizzare tramite viste il profilo comprensivo di amici e di giochi posseduti/votati?
io sto finendo ora di fare lo schema logico quindi non ho ancora affrontato il problema xD |
| Snakethesniper |
Qualcuno che ha già fatto e consegnato il progetto mi saprebbe dire se il tipo ENUM è accettato anche se non è uno standard?
|
| antares85 |
Ciao a tutti!
Domandona: la/le tabelle usate ad hoc per le materialized views sono da includere nello schema ER??? |
| Snakethesniper |
| Visto che le slide del prof riguardo la connessione al database e il passaggio dei parametri la trovo incompleta e poco chiara, qualcuno sa consigliarmi dove trovare queste informazioni? Magari relative a postgresql |
| Snakethesniper |
Qualcuno mi sa dire (se usa apache e php) che versione usa di questi?
Continuo ad avere l'errore:
Fatal error: Call to undefined function pg_connect()
nonostante abbia decommentato l'estensione che punta a pgsql.dll e seguito TUTTO quello che c'era da seguire...
sono su windows 7
edit: risolto, a quanto pare era un problema della dll nell'ultima versione |
| zandrek |
qualcuno mi sa dire una cosa: devo realizzare la funzione/trigger che cancella giochi troppo vecchi e non considerati da nessuno: so fare funzioni che si attivano in seguito ad una insert o delete o robe simili, ma come faccio ad attivare una funz/trigger in base al tempo???????
(cioè tipo far partire il trigger/funzione ogni giorno o ogni settimana) |
| number15 |
| Di solito si usa cron, ma mi sembra difficile che sia richiesto in un progettino |
| zandrek |
di cron ho letto qualcosa ma non ho la minima idea di come usarlo ...
comunque Entro pero un periodo di tempo stabilito dall'amministratore, i nuovi
gioci inseriti devono essere scelti come posseduti/provati e/o desiderati da un numero minimo di
utenti, altrimenti vengono automaticamente eliminati. Questa procedura ha lo scopo di evitare
l'inserimento di un numero eccessivo di giochi inesistenti.
se l'utente zandrek esempio segnala starcraft 2 ma rimane l'unico per due mesi a commentare/votare di starcraft 2 io toglierei starcraft2 ma come faccio a toglierlo in automatico? |
| number15 |
Non vedo alternative all'usare cron.
Per far qualcosa di simile potresti sennò fare un trigger/procedura che si attiva ad ogni inserimento di un gioco, andando a controllare se c'è qualcosa di inutilizzato da tot tempo e cancellarlo.
Non è la stessa cosa ovviamente, però è l'unica che mi viene in mente senza schedulare |
| zandrek |
riguardo la seconda parte del tuo messaggio :
Per far qualcosa di simile potresti sennò fare un trigger/procedura che si attiva ad ogni inserimento di un gioco, andando a controllare se c'è qualcosa di inutilizzato da tot tempo e cancellarlo.
era venuto in mente anche a me: cioè se un utente qualsiasi fa un'azione qualsiasi (intendo una registrazione di un nuovo utente piuttosto che l'inserimento di un gioco o voto) faccio attivare il trigger. ho solo un dubbio: se il database non viene toccato per 6 mesi non succede nulla e nessun gioco verrà mai cancellato....
per il cron ok posso fare uno script .sh ad esempio e farlo partire code:
00 00 * * * /usr/bin/cancella.sh
ogni giorno a mezzanotte però
1) dove salvo lo script sh? cioè sul mio pc ok ma come faccio a consegnarlo assieme al progetto??
2) nello script dovrei collegarmi al DB attrraverso "psql" ?
intanto grazie per le risposte... |
| gab217 |
Come gestite questa richiesta "il profilo di ogni utente comprensivo della lista amici e dei giochi posseduti e/o votati è realizzato tramite viste".
Grazie |
| zandrek |
Originally posted by gab217
Come gestite questa richiesta "il profilo di ogni utente comprensivo della lista amici e dei giochi posseduti e/o votati è realizzato tramite viste".
Grazie
io ho inteso cosi: quando sei nella pagina del tuo profilo faccio fare alla pagina php delle query sul database ma non vado nelle tabelle ma cerco nelle viste; faccio create view e poi select id_u2 from amicizia where id_u1=gab217...
edit: ovviamente nella view devono essere presenti non solo gli amici ma anche i giochi provati ecc...... |
| number15 |
Originally posted by zandrek
riguardo la seconda parte del tuo messaggio :
era venuto in mente anche a me: cioè se un utente qualsiasi fa un'azione qualsiasi (intendo una registrazione di un nuovo utente piuttosto che l'inserimento di un gioco o voto) faccio attivare il trigger. ho solo un dubbio: se il database non viene toccato per 6 mesi non succede nulla e nessun gioco verrà mai cancellato....
per il cron ok posso fare uno script .sh ad esempio e farlo partire code:
00 00 * * * /usr/bin/cancella.sh
ogni giorno a mezzanotte però
1) dove salvo lo script sh? cioè sul mio pc ok ma come faccio a consegnarlo assieme al progetto??
2) nello script dovrei collegarmi al DB attrraverso "psql" ?
intanto grazie per le risposte...
Si, ovviamente se usi un trigger e nessuno utilizza il sito, non verrà mai cancellato niente.
Per cron no idea, se ne occupa il mio collaboratore di quello :D |
| zandrek |
| proverò a sentire il prof Ferrara se ritiene accettabile il trucchetto o vuole una roba seria tipo cron o similia...intanto grazie...se poi il tuo "collaboratore" ha voglia di scrivere qua due righe è il benvenuto :D:D:D:D:D:D:D |
| pirlo21 |
vi chiedo un dubbio credo banale che mi è venuto in quanto sono poco pratico di php...
Voi come implementate le varie funzioni degli utenti? Create una pagina php per ognu funzione a sua disposizione oppure riuscite a svolgere tutto sulla stessa pagina? Ad esempio dopo il login il mio utente accede alla sua pagina utente.php
Per richiedere l'amicizia di qualcuno andrà su amici.php, per vedere la lista dei giochi andrà su giochi.php ecc ecc...
Credete sia giusto oppure c'è una soluzione per svolgere le funzioni sulla stessa pagina? |
| zandrek |
| io lascerei come hai fatto tu, magari è più carino avere meno pagine ma sono 3 punti...e ho fatto più o meno uguale.... |
| blue_tech |
ma le viste per il profilo vanno ricreate ogni volta che richiamo il profilo di un utente? (sennò non si aggiornano) mmm
cioè la sequenza in teoria è:
1) richiamo il profilo
2) creo o sostituisco la vista (per esempio che raccoglie gli amici)
3) faccio la select sulla vista per tirare fuori gli amici dell'utente in questione
che ne dite? |
| number15 |
Che viste dovete creare?
Con vista non aggiornabile si intende che non puoi aggiornare le tabelle su cui opera la vista facendo un'update sulla vista. |
| blue_tech |
le specifiche dicono che il profilo dell'utente deve essere fatto tramite viste (per mostrare gli amici, i giochi posseduti/desiderati ecc...) ora considerando che per aggiornare i dati di una vista bisogna sostanzialmente ricrearla mi chiedevo se la sequenza indicata sopra vi sembrava valida...  |
| number15 |
La vista (NON materializzata) non è altro che una query.
Non necessita di nessun aggiornamento, visto che ogni volta che la chiami riesegue la query in quel momento.
Es. tu crei questa vista che ti estrae le varie coppie gioco/utente
create view giochi_utenti as
select g.id_gioco, gioco, u.id_utente, utente
from utente u, gioco g, gioco_utente gu
where u.id_utente = gu.id_utente and g.id_gioco = gu.id_gioco
Ora quando la chiami con
select * from giochi_utenti
viene eseguita semplicemente la query contenuta nella vista.
Il concetto di vista non aggiornabile (solitamente quando formata da join tra più tabelle) è che NON puoi fare:
update giochi_utenti set gioco = 'nba 2k11' where id_gioco = 10 |
| blue_tech |
ok questo lo so però le viste vengono usate come fossero tabelle in modo che le operazioni vengano fatte su un sottoinsieme di tutti i possibili dati...
questo mi fa pensare che se io devo visualizzare qualcosa:
1) creo la vista che corrisponderà al risultato della query in quel momento
2) faccio le query che mi servono sui dati nella vista invece che su tutte le tabelle complete
3) quando eseguo un aggiornamento del database (quindi delle tabelle principali -> per esempio aggiungo un amico) le viste non si aggiornano in automatico ma continuano a mostrare i dati di quando le ho create (quindi l'amico appena aggiunto non risulta nella vista) e quindi ogni volta che io chiamo la pagina devo ricreare le viste per aggiornare i dati che queste contengono.
Voglio capire se questa mia visione delle cose è giusta o no. |
| number15 |
Allora stai parlando di viste materializzate ed è tutt'altro discorso.
Qualche post prima se ne parlava e ho postato un link ad un altro ragazzo su come gestirle.
Prova a darci un'occhiata
Edit: eri tu :D
Comunque mi sfugge il senso di tutto ciò: dove sta il vantaggio a materializzare quella vista, se devi sempre ricrearla ad ogni aggiornamento?
Ho dato un'occhiata al progetto: per me intende altro.
Originally posted by progetto
L'utente analista ha funzioni di monitoraggio della comunita. Egli ha accesso a un insieme di statistiche. In particolare, per ogni utente e possibile calcolare un profi lo che
riporta il numero di giochi posseduti/provati in relazione al numero medio dei giochi posseduti/provati da tutti gli utenti.
Tutte le funzioni di statistica per l'utente analista sono materializzate e memorizzate in opportune tabelle nella base di dati. E' pertanto necessario realizzare gli opportuni trigger che
mantengano aggiornate tali informazioni a seguito dell'inserimenti di nuovi giochi, dell'acquisizione di nuovi voti e opinioni sui giochi esistenti, e della de nizione di nuove relazioni di amicizia
fra utenti.
Secondo me intende tipo che il numero di giochi posseduti lo devi salvare in una tabella, cioè metti un campo giochi/posseduti in utente e fai un trigger che ad ogni 'associazione' ti aumenta di 1 il campo.
|
| blue_tech |
no no allora se vedi l'ultima frase del punto 2 che viene dopo quello che hai riportato, parla del profilo dell'utente.
in sostanza lui vuole che siano usate viste materializzate per le funzioni di statistica e (ho parlato col prof) le informazioni devono proprio essere salvate come tabelle su DB. Quindi lui mi ha detto fai la vista con una select e la salvi su db come fosse una tabella.
poi l'ultima frase dice: "Il profilo di ogni utente comprensivo della lista di amici, dei giochi posseduti e/o votati è realizzato tramite viste"
e qui presumo si intendano viste normali e non materializzate.
la differenza sta solo nel fatto che i dati non vengono fisicamente salvati in una tabella su db ma le viste all'atto pratico vengono usate come fossero tabelle anche se sono virtuali.
per quello penso che per aggiornare una vista l'unico sistema sia ricrearla ogni volta (come viene poi fatto anche nell'articolo che mi hai linkato)
EDIT: è proprio perchè anche a me sfugge il senso di ricreare ogni volta le viste che sto cercando di capire se sto ragionando bene oppure no. |
| number15 |
Se te l'ha detto il prof, allora fai come dice lui e copia dal link il procedimento. Mi pare sia fatto bene.
Ad ogni inserimento/aggiornamento (trigger) richiami la cancellazione e creazione della tabella con i dati che ti servono e poi le query del profilo le fai su questa nuova tabella.
In pratica riflettendoci il vantaggio sarebbe che esegui la query 'pesante' solo in caso di aggiornamento di quelle tabelle e non ogni volta che devi visualizzare il profilo.
Il poco senso è che sarà una query con 3 join quindi....
Edit: non pensarle come viste, pensale come tabelle di analisi (report), sennò fai confusione. |
| blue_tech |
| ok ma a questo punto mi comporto così sia con le viste materializzate che con quelle non materializzate giusto? o meglio più che giusto, ti sembra sensato? :P |
| number15 |
| no, le non materializzate una volta che le hai create si aggiornano da sole, non son altro che una scorciatoia: al posto di riscrivere la query con le join ogni volta, fai una select * sulla vista. |
| asgar |
io ho un dubbio ancora più generale.. a che servono le viste per il profilo?
non si fa prima a mettere sulla pagina i dati dell'utente ed i giochi che possiede/vorrebbe facendo una query su quelle tabelle?
cioè, non saprei proprio che dati mettere nella vista senza creare ridondanza, voi come lo gestite? |
| number15 |
Crei la vista che fa le query che ti servono e utilizzi quella nella pagina.
Ovviamente a sto livello le viste servono a poco, però pensa se al posto di avere 'il sito' dove vedere i profili, dovresti controllarli da phpmyadmin, sqlyog o simili.
Dovresti ogni volta riscriverti la query con le join, mentre se ti sei fatto la vista è tutto già pronto. |
| asgar |
ok proverò ad implementarle così :)
il fatto di cancellare un gioco che non è stato aggiunto da nessuno invece come lo gestite? |
| pirlo21 |
qualcuno mi saprebbe dire dove metterebbe i trigger nel progettino? non ne vedo molta necessità...
e poi nel testo c'è scritto che le amicizie e il profilo degli utenti sono gestiti tramite viste, mentre le statistiche in tabelle (aggiornate con trigger)
questo vuol dire che dobbiamo creare delle tabelle apposite x contenere i dati delle statistiche e le viste x ciò che riguarda l'utente?
Oppure vuol dire che i dati per le statistiche li estrapoliamo direttamente dalle tabelle, mentre per gli utenti passiamo tramite le viste? |
|
|
|
|
