.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)

Progetto Basi 2011/2012

Apro questo thread nella speranza che sia di aiuto per tutti quelli che devono fare il progetto di basi di dati! Magari scambiandoci info, conoscenze ecc possiamo aiutarci tutti quanti a finire questo benedetto progetto! Qualcuno lo ha già iniziato?? Domanda stupida...se ho la presenza di 3 categorie (utente reg, utente nonreg, admin) dovrò avere una tabella anche per questi nel mio database o è una cosa completamente a parte legata solo al php???

certo!!per amministratore e per utente registrato sicuramente , per quanto riguarda l ultente non registrato no perche non deve esserci login..in poche parole l ultente non registrato è il visitatore occasionale quindi non deve esseere identificato da nulla

quanto tempo si ha a disposizione per fare il progetto?

__________________
Perché, mentre il manganello può sostituire il dialogo, le parole non perderanno mai il loro potere; perché esse sono il mezzo per giungere al significato, e per coloro che vorranno ascoltare, all'affermazione della verità. E la verità è che c'è qualcosa di terribilmente marcio in questo paese. (V)

I popoli non dovrebbero aver paura dei propri governi, sono i governi che dovrebbero aver paura dei popoli. (T.J)

1 anno

dove trovo la traccia del progetto?
mentre per quanto riguarda l'orale ?

Grazie Maddy

__________________
Perché, mentre il manganello può sostituire il dialogo, le parole non perderanno mai il loro potere; perché esse sono il mezzo per giungere al significato, e per coloro che vorranno ascoltare, all'affermazione della verità. E la verità è che c'è qualcosa di terribilmente marcio in questo paese. (V)

I popoli non dovrebbero aver paura dei propri governi, sono i governi che dovrebbero aver paura dei popoli. (T.J)

Originally posted by SanJuanWolf89
certo!!per amministratore e per utente registrato sicuramente , per quanto riguarda l ultente non registrato no perche non deve esserci login..in poche parole l ultente non registrato è il visitatore occasionale quindi non deve esseere identificato da nulla

Hai fatto il diagramma ER?
Da lì vedi i collegamenti tra le varie tabelle.
A livello logico le tabelle saranno poi 'collegate' dalla chiavi esterne.

A livello applicativo la tabelle utente ti servirà anche per mostrare/offrire funzionalità diverse a seconda della tipologia di utente

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

Allora:
tabella utenti registrati(
dati.. (id login e password)
)

taabella amministratore(
dati...
)

tabella annuncio(
dati tra cui riferimento all'utente che l ha pubblicato, ovvero riferimento alla tabella utente registrato
)

in poche parole ogni annuncio viene pubblicato da un utente nella tabella annuncio avrai una colonna utente

Che dati andresti a mettere in AMMINISTRATORE?

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

Ma (ai fini del progetto) io dovrei creare degli utenti fittizi nella mia base di dati oppure devo poter aggiungere degli utenti? Nel senso...ok un utente registrato pubblica un annuncio e quindi quel determinato annuncio si riferisce all'utente che l'ha pubblicato. Ma per gli utenti che visitano semplicemente la base di dati ( e che quindi non hanno nessun riferimento alla tabella annunci) deve essere creata una tabella a parte?? Nella tabella amministratore io metterei semplicemente la mia user e la mia password dato che presuppongo di essere l'unico amministratore del mio DB o no?

La popolazione del database viene ovviamente fatta 'a monte'.
Il fase di discussione del progetto però il prof. può chiedere l'iscrizione di un utente al sito attraverso il form di registrazione.
A quel punto ovviamente l'utente andrà salvato.
Non so se son previsti pannelli per poter inserire annunci. Il tal caso potrebbe chiederti di inserire un annuncio e di associarlo ad un utente.

Per i visitatori, quindi utenti NON registrati, che dati andresti a salvare in una tabella?

Per quale motivo per salvarti la user e la password dell'admin creeresti una tabella amministratore?

Ps. sto cercando di farti(vi) ragionare. Se preferisci risposte più dirette e 'concrete' dimmelo

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

Gentilissimo Comunque in effetti io non creerei una tabella amministratore, era per rispondere alla domanda che hai rivolto a SanJuanWolf89! Io creerei una tabella UTENTE con attributi nomeUser, password, tipoUser. nomeUser diventerebbe chiave esterna per il collegamento con la tabella ANNUNCIO, mentre tipoUser (che avrebbe dominio: user, admin) servirebbe per individuare il ruolo dell'utente all'interno del database. Può essere una soluzione sensata?

PS: comunque appena terminerò lo schema ER lo posto e approfitterò nuovamente della tua pazienza per eventuali consigli

È ovviamente la soluzione corretta ;-)

Un consiglio: utilizza sempre un campo intero (int, smallint ecc) AUTO INCREMENT come identificativo/chiave primaria ed eventualmente metti come UNIQUE username o mail o entrambi (non la coppia).
Quando devi poi creare delle chiavi esterne, avrai degli int da confrontare e non delle stringhe.
Come prestazioni c'è un abissso!

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

quindi aggiungo alla tabella UTENTE un campo id (integer) che fa riferimento alla tabella annunci?

Si.
TI faccio un esempio ("pseudocodice"):
UTENTE(id_utente, username, password, email, tipo_utente);
id_utente MEDIUMINT AUTO_INCREMENT;
PK(id_utente);
UNIQUE(email);
UNIQUE(username);

ANNUNCI(id_annuncio, xxx,xxx, id_utente);
FK(id_utente) REFERENCES utente(id_utente);

E' l'id_utente in annunci che fa riferimento ad utente e non il contrario

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

Come sempre grazie per le risposte e la pazienza Mi potresti spiegare che differenza ci sarebbe se fosse il contrario??

PS: ho scaricato e installato apache sul mio portatile. Ora per completare l'opera dovrei scaricare php , postgres e phppgadmin per poter lavorare nello stesso ambiente del laboratorio di DB. Qualcuno riesce a trovare un link decente per scaricare php?? Non riesco a trovare nessun installer, solo file zip pieni di cartelle e altri file php e sinceramente non so cosa farne -.-

Semplicemente tu la chiave esterna la metti su una chiave peimaria di un altra tabella. Quindi tu crei id_utente in Utente come chiave primaria mentre id_utente in Annunci è chiave esterna riferita a id_utente in Utente. Questo garantisce che ogni annuncio sia associato ad un utente esistente nella base di dati.

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

Non riesco a trovare nessun installer, solo file zip pieni di cartelle e altri file php e sinceramente non so cosa farne -.-

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

@number15: tutto chiaro grazie

@cowboy: apache è installato e funzionante. Avevo gia scaricato lo zip di php per windows, estratto i file all'interno di una cartella che ho chiamato php, e messo la cartella in C:\ . Ho trovato una guida sull'installazione di apache-php-postgres..secondo questa all'interno del mio zip dovrei avere un file php5ts.dll (che manca) che va messo nella cartella WINDOWS. C'è scritto poi di editare il file httpd.conf (nella cartella apache) inserendo 3 righe di codice. Seguo tutte le istruzioni alla lettera ma il mio simpaticissimo portatile mi dice che non posso editare il file httpd.conf perchè non riesce a trovare il path penso di essere vicino all'esaurimento!

hehe... te l'ho detto di liberare un paio di chakra

L'installazione all'inizio sembra complicata, dagli un'altra chance. Nel frattempo vedo se riesco a trovare il materiale del progetto dove ho tenuto un diario dell'istallazione

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

Il file httpd.conf lo trovi (normalmente, per la versione 2.2) sotto:

C:\Programmi\Apache Software Foundation\Apache 2.2\conf\

Quindi vai sul Prompt, posizionati sulla cartella conf e scrivi:

notepad httpd.conf > invio

Al file di configurazione io ho aggiunto le seguenti 5 righe:

LoadModule php5_module "PHPinstallDIR/php5apache2.dll"
AddType application/x-httpd-php .php
PHPIniDir "PHPinstallDIR"
DocumentRoot "C:/prog"
LoadFile C:/Programmi/PostgreSQL/8.4/bin/libpq.dll

La riga Document root era dove io avevo i file del mio progetto. Attenzione anche alle cartelle nominate secondo le versioni, le mie e le tue non coincidono.

Se, come me, hai estratto i file di php sotto C:\php allora:

1- copia il file php.ini-recommended (del zip) nella cartella di estrazione
2- copia le seguenti librerie nella cartella di estrazione(ricontrollare le versioni):
- fdftk.dll
- libmysql.dll
- php5apache2_2.dll
- php5ts.dll

3- copiare il contenuto della cartella ext nella cartella [/b]extensions[/b]
4- modificare il contenuto di php.ini (il file al punto 1, rinominato) come segue, alcune voci sono presenti nel file:

include_path = "PHPinstallDIR\includes"
extension_dir = "PHPinstallDIR\extensions"
extension = php_mysql.dll
extension = php_pgsql.dll
extension = php_xsl.dll

5- riavvia il sistema (anche se fai delle modifiche minori)

Buon progetto!

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

Grazie per la spiegazione CowBoy!

Rispondo a pintu...se fosse il contrario ogni utente sarebbe collegato a un solo annuncio invece ogni utente puo pubblicare qnt annuncio vuole..


Per quanto riguarda gli utenti non registrati io nn ho fatto alcuna tabella xk nn sn necessarie credenziali per verificarne l'accesso.
Per l amministratore invece si perche cmq l amministratore anche se uno solo ha un login e una password

Infine rispondo a number15..non sono daccordo sulla tua decisione d mettere come primary key l'id utente..io ho messo come primary key il nome dell'utente proprio cm succede qnd t registri da qualche parte...quello che è unico è il nome dell'utente e se e gia occupato da qlkn altro risulta non disponibile

Dal testo del progetto:

"Utente registrato. Ha accesso al sistema mediante credenziali e può pubblicare annunci. Gli utenti registrati possono essere privati o agenzie. Il contatto dell'utente registrato che ha pubblicato l'annuncio è sempre visibile mentre l'insieme completo dei dati di registrazione di un utente è disponibile per la consultazione solo da parte degli amministratori del sistema."

1) "Gli utenti registrati possono essere privati o agenzie."

E' una richiesta che comporta le opportune modifiche al dbms o no? Nel senso...nella mia tabella UTENTE potrò avere 'gli utenti pinco pallino' e 'azienda srl' senza preoccuparmi del fatto che uno sia un privato e l'altro un azienda o secondo voi è necessario aggiungere alla tabella l'attributo 'tipoUtente' con dominio (privato, azienda)??

2)"Il contatto dell'utente registrato che ha pubblicato l'annuncio è sempre visibile mentre l'insieme completo dei dati di registrazione di un utente è disponibile per la consultazione solo da parte degli amministratori del sistema."

Ciò significa che un (utente registrato e non) può sapere solo che un certo annuncio è stato pubblicato da 'pincopallino' mentre l'amministratore può vedere tutte le info come nome, cognome, password?

So che sono domande banali ma prima di mettermi a smanettare volevo avere delle certezze su come impostare le tabelle

Originally posted by SanJuanWolf89

Infine rispondo a number15..non sono daccordo sulla tua decisione d mettere come primary key l'id utente..io ho messo come primary key il nome dell'utente proprio cm succede qnd t registri da qualche parte...quello che è unico è il nome dell'utente e se e gia occupato da qlkn altro risulta non disponibile

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

Originally posted by pintu
Dal testo del progetto:

"Utente registrato. Ha accesso al sistema mediante credenziali e può pubblicare annunci. Gli utenti registrati possono essere privati o agenzie. Il contatto dell'utente registrato che ha pubblicato l'annuncio è sempre visibile mentre l'insieme completo dei dati di registrazione di un utente è disponibile per la consultazione solo da parte degli amministratori del sistema."

1) "Gli utenti registrati possono essere privati o agenzie."

E' una richiesta che comporta le opportune modifiche al dbms o no? Nel senso...nella mia tabella UTENTE potrò avere 'gli utenti pinco pallino' e 'azienda srl' senza preoccuparmi del fatto che uno sia un privato e l'altro un azienda o secondo voi è necessario aggiungere alla tabella l'attributo 'tipoUtente' con dominio (privato, azienda)??

2)"Il contatto dell'utente registrato che ha pubblicato l'annuncio è sempre visibile mentre l'insieme completo dei dati di registrazione di un utente è disponibile per la consultazione solo da parte degli amministratori del sistema."

Ciò significa che un (utente registrato e non) può sapere solo che un certo annuncio è stato pubblicato da 'pincopallino' mentre l'amministratore può vedere tutte le info come nome, cognome, password?

So che sono domande banali ma prima di mettermi a smanettare volevo avere delle certezze su come impostare le tabelle

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

Non avevo minimamente pensato a "contatto" in quel senso ahah xD Comunque volevo lasciarla visibile all'admin così se un utente l'ha dimenticata in qualche modo si recupera

Se scegli di non criptare allora sì, altrimenti ne dovresti creare una nuova in caso di dimenticanza.

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

Originally posted by number15
Ciao, è ovviamente giusto anche la tua scelta ma pensa all'alla gestione/ottimizzazione di un database.
Ad esempio con la tua scelta la chiave esterna in annuncio sarà un varchar(20) mentre potrebbe essere uno smallint unsigned.
Quindi le join saranno molto più 'pesanti'.
Per indicare come unico un campo si usano gli indici Unique: in questo caso puoi farne due, uno per username e uno per email.
In ogni caso i controlli saranno gestiti dall'applicazione web e non dal database, cioè prima del db sarà l'applicazione a dirti che esiste già un utente con quello username.

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

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

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

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

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

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

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?

È 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

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.

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

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??

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]

??

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??

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]

??

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

@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

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!

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

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

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

Aspè non ho capito..ti riferisci alla parte dei criteri di similarità?

No, parlo in generale.

Ps. mandami pm con msn o skype che se vuoi dopo pranzo ti aggiungo e ti chiarisco un paio di cose, così velocizziamo la discussione (oggi pomeriggio devo per forza mettermi a far progetto di algo )

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

la domanda era riferita a SanJuanWolf89 Per quello che gli hai risposto tu sono d'accordo sul fatto che sia abbastanza inutile la tabella CONTRATTO anche se io l'ho fatta all'inizio.. Cmq una volta terminato lo schema er e concettuale provo a fartelo vedere cosi magari uso i tuoi preziosi consigli

PS: è già uscito il progetto di algoritmi??

Ah ok

Comunque se sei ancora alla schema ER basta che ci metti una croce sopra a CONTRATTO e bon
In generale comunque lo schema ER cerca di tenerlo il più semplice possibile... esplichi poi tutto meglio effettuando le dovute trasformazioni nel relazionale

Se ho tempo ti aiuto volentieri, è l'unico esame che mi è piaciuto e ho trovato utile.

PS: si, ultimo appello di Torelli per i fuoricorso. Il nuovo appello deve ancora uscire e prevede mi pare dei compitini.

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

sisi cmq lo so k e abbastanza inutile xo mi e servita x la questione dei cluster..perchè ho deciso di raggruppare per tipo contratto e costo immobile quindi per definire i parametri mi serviva una tabella tipo contratto..

Tecnicamente cosa intendete con cluster? SOn delle 'viste materializzate'?

In ogni caso mi sfugge come una tabella CONTRATTO, usata per specificare le tipologie di contratto possibili, ti possa risolvere di problemi... dovrai sempre avere una chiave esterna in ANNUNCIO per specificare il tipo di contratto su cui joinnare la tabella CONTRATTO.

A quel punto tanto vale usare un campo enum tipo_contratto in annuncio e arrivi alla stessa situazione.

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

Ciao a tutti, mi aggiungo anch'io a questa conversazione e riporto l'attenzione sulla questione "categorie"

Non mi è molto chiaro cosa intende il testo quando scrive "Le categorie possono avere caratteristiche specifiche"
Per esempio la categoria "condominio" avrà la caratteristica "presenza del portiere", mentre quella "ufficio" avrà la caratteristica "numero di prese ethernet" (sto sparando a caso)?
Quindi in pratica la categoria influenza il numero e tipo di attributi di un annuncio?
Anche voi l'avete interpretata così? E nel caso come si descrive questa situazione mediante un diagramma ER o relazionale?

__________________
Eidolon64|Blog

Ciao, dai un occhio alla pagina precedente in cui se n'è discusso un minimo.

La questione è spinosa. Io risolverei 'adattando' le specifiche (senza senso) ad una implementazione più sensata.

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

Grazie, sei stato molto chiaro!
A naso io preferirei la seconda opzione, alla fine non dovrebbero venire fuori tante categorie diverse, né cambiare molto col tempo (pensando all'espandibilità)

__________________
Eidolon64|Blog

Si, direi che è la scelta più sensata.

Vedi tu se associarla ad annuncio o ad immobile, anche se le specifiche sembrano abbastanza propense verso annuncio, ma per me è sbagliato

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

Originally posted by number15
Si, direi che è la scelta più sensata.

Vedi tu se associarla ad annuncio o ad immobile, anche se le specifiche sembrano abbastanza propense verso annuncio, ma per me è sbagliato

__________________
Eidolon64|Blog

Nelle specifiche non sembra esser richiesto, ma mi sembra scelta saggia

Già solamente nel caso decidessi di mettere in vendita e in affitto lo stesso immobile oppure di rimettere in vendita lo stesso immobile dopo la scadenza del primo annuncio dovresti riscrivere in annuncio tutti i campi (che saranno una decina) relativi a quell'immobile (tra l'altro a rischio violazione della 3° forma normale)

Ma poi proprio concettualmente sono entità diverse!

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

Ha tutto molto senso xo scusa quando un utente inserisce un annuncio cosa succede..si va a inserire una tupla sia in IMMOBILE, sia in ANNUNCIO??

La tua idea quindi e di tenere due relazioni,una x gli annunci visibili (ANNUNCIO) e una per tutti gli immobili..ma non si crea un po d confusione cosi??Soprattutto per quanto riguarda le funzioni di ricerca e di clustering. X me esce un po dagli schemi anke xk il testo parla esplicitamente di annuncio, cioe la fa mooolto piu facile di cosi anche se è un ottima idea.

Guarda t propongo una soluzione
tabella annuncio(
id, titolo, citta, categoria, lat, lon, costo, prezzo, ecc ecc)

tabella caratteristiche(
id_annuncio, portineria, giardino, ecc ecc
)

in questo modo non suddividi troppo annuncio da immobile

Si, ovviamente si complica il tutto, ma è strutturalmente molto più corretto. Per le funzioni da implementare in questo progetto probabilmente non ti serve nè ti porta alcun vantaggio, però se progetti pensando a futuri sviluppi non si può tralasciare questo aspetto.

Dato che non è richiesto dalle specifiche, puoi tranquillamente non farlo, così eviti di incasinarti troppo se non hai troppa padronanza con la materia.

Nel caso lo facessi ovviamente in fase di inserimento devi inserire nelle due tabelle, associando ad annuncio la chiave dell'immobile inserito.
Se l'immobile è già presente invece devi solamente inserire in annuncio.

Con una semplice join arrivi allo stesso punto di avere un'unica tabella, quindi per le funzioni di ricerca ti cambia relativamente.
Tra l'altro leggo che richiede viste materializzate, quindi a maggior ragione cambia nulla.

Mi dite cosa intende per clustering? Oltre che concettualmente, proprio tecnicamente vorrei sapere come andrebbero implementati questi raggruppamenti.
Perché se è quello che intendo io, va fatto con tecniche di partizionamento che mi sembra tutt'altro che semplice.

Per quanto riguarda la tua soluzione per me è 'scorretta' per due motivi:
1) come vedi avrebbe più senso legarla ad immobile e non ad annuncio (è l'appartamento ad avere la portineria, non l'annuncio: lo stesso appartamento avrà la portineria in tutti gli annunci che gli associ)
2) non c'è motivo di dividere in due tabelle quegli attributi che saranno sempre da esplicare per ogni annuncio, dato che non splitti in base alla categoria di immobile.

Guarda qualche post sopra che se ne è discusso. Direi che ad occhio quelle son le uniche due opzioni valutabili.

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

Raggruppamento per similarita. Gli annunci possono essere raggruppati in cluster sulla
base di criteri di similarita. Un cluster e un gruppo di annunci che risultano simili rispetto
a un dato criterio. Ad esempio, utilizzando la vicinanza geograca come criterio di simila-
rita, si otterranno cluster che raggruppano annunci di immobili collocati in aree vicine. Il
1Lo studente decide a priori e documenta le tipologie disponibili.
2
criterio di similarita puo essere dotato di parametri che ne in
uenzano il comportamento2.
Un esempio di parametro e la tolleranza che stabilisce la soglia entro la quale considerare
simili due annunci. Ad esempio, utilizzando la vicinanza geograca come criterio, la tolle-
ranza puo essere di 10km per fare in modo che gli annunci di immobili nel raggio di 10km
vengano raggruppati nel medesimo cluster. Il sistema deve supportare ALMENO 2 criteri
di similarita dierenti. Il criterio per vicinanza geograca deve essere obbligatoriamente
supportato dalla base di dati. Gli utenti registrati e non registrati possono visualizzare gli
annunci raggruppati in cluster secondo un criterio di similarita predenito scelto dall'am-
ministratore dell'applicazione. L'amministratore puo cambiare la visualizzazione in cluster
selezionando un diverso criterio di similarita tra quelli supportati dall'applicazione. Nella
realizzazione del progetto, si consideri che l'inserimento, la modica e la cancellazione di
annunci richiede l'aggiornamento dei cluster.

io l'ho implementato cn le viste materializzate con opportuni trigger

Si, avevo capito a cosa servissero, ma non mi era ben chiaro come volesse che fosse realizzato il tutto.

Spero vivamente che dobbiate farlo con le viste materializzate, ma il dubbio mi era sorto perché sopra parla chiaramente di viste materializzate

E’ pertanto necessario realizzare gli opportuni trigger che mantengano aggiornate tali viste in relazione all’inserimento
o alla modifica di annunci.

Nella realizzazione del progetto, si consideri che l'inserimento, la modica e la cancellazione di annunci richiede l'aggiornamento dei cluster.

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

Gia ma dato k alle lezioni ci siamo concentrati soprattutto sullòe viste m. e dato che il partizionamento in laboratoriomanco l abbiamo fatto io l'hoimplementato cosi e x questo per nn rendere troppo complesso il tutto ho usato una sola tabella annuncio..cmq è un ottima soluzione anke la tua

Come ti ho detto credo e spero che voglia viste materializzate

Usare solo la tabella annuncio rispetta le specifiche quindi è senz'altro corretto.

Quando diedi io l'esame era espressamente richiesto che fosse tutto in terza forma normale.
Ora nel testo non lo vedo scritto, ma dateci un occhio comunque che potrebbero chiedervelo in fase di discussione del progetto.

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

sISI poi cmq il prof ha dtt k c possono essere diverse soluzioni quindi io l ho implementato cosi..inoltre a me ha dtt espressamente che vogliono vedere cm facciamo i trigger quindi penso si concentrino su quello sopratutto

Se ti vengono i trigger sei già a buon punto, dato che spesso è la cosa più ostica da gestire, o meglio, si sbaglia sempre qualcosa nella sintassi agli inizi.

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

Ragazzi ma per quanto riguarda il raggruppamento di similarità della vicinanza geografica, io ho trovato questa formula:

Siano x1, y1, x2, y2 la latitudine (x) e la longitudine (y) rispettivamente dei punti A e B; sia DELTA1 la differenza tra le due longitudini e DELTA2 la distanza angolare tra i due punti considerati (A,B).
La distanza angolare tra A e B è data dalla formula:

DELTA1 = y1 - y2
DELTA2 = arccos(sin(x1)*sin(x2) + cos(x1)*cos(x2)*cos(DELTA1))

Sia R il raggio della terra arrotondato e D la distanza in Km tra A e B.
La distanza in Km tra A e B è data dalla formula:

R = 6360
D = DELTA2*R

Qualcuno ha fatto così?
Inoltre usando questa formula, dovrei basarmi su una coppia di coordinate "prestabilite" per verificare la vicinanza con tutte le altre coppie. Quale coppia di coordinate "prestabilite" scegliere?

Fatemi sapere, grazie!

Originally posted by spikey

Inoltre usando questa formula, dovrei basarmi su una coppia di coordinate "prestabilite" per verificare la vicinanza con tutte le altre coppie. Quale coppia di coordinate "prestabilite" scegliere?

Fatemi sapere, grazie!

__________________
Eidolon64|Blog

@Spikey
Io in altri progetti utilizzo questa formula:
SELECT ROUND(((ACOS(SIN($lat * PI() / 180) * SIN(t.lat * PI() / 180) + COS($lat * PI() / 180) * COS(t.lat * PI() / 180) *
COS(($lon - t.lon) * PI() / 180)) * 180 / PI()) * 60 * 1.1515 $unit), 2) AS distance
FROM table t
$unit = '*1.609344' per i km
$lat e $lon sono le coordinate dell'oggetto che si prende come riferimento.

Questo però non fa quello richiesto dal progetto, perché i raggruppamenti vanno fatti a monte e soprattutto non rispetto ad un punto sulla mappa, ma rispetto ai vari punti sulla mappa.

@Shaper
Credo possa essere una buona soluzione: l'unico dubbio è che solitamente non sono richieste particolari algoritmi a livello di programmazione, e in questo caso non mi pare proprio semplicissimo.

Onestamente non saprei proprio aiutarvi su sta cosa.
Tra l'altro è una funzione di cui non capisco l'utilità.

Boh boh, mi vien da pensare però che ci voglia per forza un punto di riferimento.

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

Scusate una cosa che non centra niente..qualcuno sa se per lo scritto di basi c'è il salto appello?

Originally posted by pintu
Scusate una cosa che non centra niente..qualcuno sa se per lo scritto di basi c'è il salto appello?

__________________
Eidolon64|Blog

Ciao a tutti.
Anche io sono in procinto di consegnare il progetto ma ancora non ho trovato un modo logico di risolvere la questione della divisione in cluster... Ho pensato di "farla sporca" e implementare una funzione che ritorni, usando la funzione distanza, tutti gli annunci entro un raggio di N Km da un dato annuncio. Funzione che poi andrei ad usare nella visualizzazione del singolo annuncio dove visualizzerei tutti gli annunci che distano al massimo N Km dall'annuncio visualizzato.

Questa cosa però non mi convince perchè sembra dal testo che la divisione in cluster vada fatta quando si inserisce un nuovo annuncio e tutto vada salvato nel db. Ma come si può suddividere gli annunci in distanza senza avere un punto da cui calcolare le distanze?

Quanlcuno di voi ha avuto qualche idea in merito?

Originally posted by basettoni
Ciao a tutti.
Anche io sono in procinto di consegnare il progetto ma ancora non ho trovato un modo logico di risolvere la questione della divisione in cluster... Ho pensato di "farla sporca" e implementare una funzione che ritorni, usando la funzione distanza, tutti gli annunci entro un raggio di N Km da un dato annuncio. Funzione che poi andrei ad usare nella visualizzazione del singolo annuncio dove visualizzerei tutti gli annunci che distano al massimo N Km dall'annuncio visualizzato.

Questa cosa però non mi convince perchè sembra dal testo che la divisione in cluster vada fatta quando si inserisce un nuovo annuncio e tutto vada salvato nel db. Ma come si può suddividere gli annunci in distanza senza avere un punto da cui calcolare le distanze?

Quanlcuno di voi ha avuto qualche idea in merito?

__________________
Eidolon64|Blog

Originally posted by Shaper
Come ho detto qualche post fa, l'algoritmo Dbscan fa proprio questo: divide un insieme di punti in cluster, senza la necessità di fornirgli nessun parametro a parte il numero minimo di punti che deve avere un cluster per essere considerato tale e la soglia.
Io lo sto implementando e credo di avere quasi finito: è un po' una rottura, ma è fattibile, con un po' di manipolazione di array.

Più che altro, ma poi il risultato dev'essere memorizzato nel database? Se faccio in modo che venga eseguito l'algoritmo ogni volta che si vogliono visualizzare i cluster non va bene lo stesso? Ok, come efficienza non sarà il massimo, ma non stiamo parlando di algoritmi poi così eterni..

Se si parla di cluster nel vero senso, si, la divisione va memorizzata.
Cerca tecniche di partitioning in mysql su Google e ci dovrebbero essere alcuni esempi di cluster: in pratica diciamo che divide una tabella in n tabelle sulla base di un campo. Ad esempio dividi per anno di nascita gli utenti e in inserimento la persona finirà nella tabella del suo anno.

Per me la richiesta è complicatissima, costosissima e senza senso.
Io penserei o ad una divisione a zone o alla distanza dal punto prescelto, conscio del fatto che non sia quello richiesto nelle specifiche.
Avete provato a sentire la prof.?

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

Originally posted by basettoni
A pagina 3 dice:
"... si consideri consideri che l'inserimento, la modifica e la cancellazione di annunci richiede l'aggiornamento dei cluster."

__________________
Eidolon64|Blog

Per questo motivo sostengo quanto scritto sopra, perché essendo un cluster basato su confronti ad ogni inserimento dovresti ricreare le tabelle, perché la posizione di un nuovo immobile ti cambia tutte le distanze. Inoltre vuole la possibilità di cambiare il numero della distanza.

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

Originally posted by number15
Per questo motivo sostengo quanto scritto sopra, perché essendo un cluster basato su confronti ad ogni inserimento dovresti ricreare le tabelle, perché la posizione di un nuovo immobile ti cambia tutte le distanze. Inoltre vuole la possibilità di cambiare il numero della distanza.

__________________
Eidolon64|Blog

In ogni caso concordo sul fatto che, messa così come nelle specifiche, è una funzione costosa, complessa e completamente inutile!

__________________
Eidolon64|Blog

E poi per quanto ho capito, chiede di creare cluster di "dimensione di 10km" mentre tutti gli algoritmi di clustering che ho visto parlano di "soglie tra punto e punto".

Originally posted by Shaper
Sì, ma se io mi faccio una funzione clusterizza() e la invoco, a partire dallo stato attuale del DB, ogni volta che ho bisogno dei cluster (sia utenti normali sia amministratori), per l'utente il risultato è identico.

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

Originally posted by number15
Sì, ho capito, ma non è un cluster
Il cluster è la livello di db, non di applicazione.
Per questo ti avevo detto che poteva essere un metodo corretto quell'algoritmo, il ma mi sembrava troppo complesso per un esame di database.

__________________
Eidolon64|Blog

Si, cioè il clustering è proprio quello. Serve quando hai tabelle enormi per velocizzare le query. Dividi la tabella in più tabelle sulla base di un campo e tutti le query andranno fatte sulle corrispondenti tabelle, quindi quando fai una select dall'applicazione devi eseguirla sulla tabella corretta.

Detto ciò, in questo caso non è fattibile perché il tuo partizionamento non è fisso, ma varia ad ogni inserimento dato che le distanze sono calcolate tra immobili e non rispetto ad un punto stabilito.

Edit: questo Link spiega bene come funziona il partizionamento : http://www.stardata.it/le-novita-di-mysql-5-1-186/

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

Originally posted by number15
Si, cioè il clustering è proprio quello. Serve quando hai tabelle enormi per velocizzare le query. Dividi la tabella in più tabelle sulla base di un campo e tutti le query andranno fatte sulle corrispondenti tabelle, quindi quando fai una select dall'applicazione devi eseguirla sulla tabella corretta.

Detto ciò, in questo caso non è fattibile perché il tuo partizionamento non è fisso, ma varia ad ogni inserimento dato che le distanze sono calcolate tra immobili e non rispetto ad un punto stabilito.

Edit: questo Link spiega bene come funziona il partizionamento : http://www.stardata.it/le-novita-di-mysql-5-1-186/

__________________
Eidolon64|Blog

Scusate ma sulla consegna parla chiaro "annunci di immobili nel RAGGIO di 10 km" quindi ne deduco che per forza bisogna considerare un punto centrale. Quindi il parametro che influenza il fatto che un annuncio sia raggruppato o meno è proprio la distanza da questo punto centrale non la distanza tra un annuncio e l'altro. Questo proprio perchè sul testo parla di raggio

Originally posted by Shaper

Che voi sappiate, sono molto fiscali nella correzione o accettano scelte un po' alternative, se ben documentate?

ciao a tutti
ma per quanto riguarda le viste materializzate come le avete svolte?

Io avrei un po di domande a carattere generale sul progetto anche perchè è da un po che l'ho iniziato ma non riesco a venire a capo di alcune cose.

Inizierei dalle tabelle:
bisogna mettere + tabelle possibile o generalizzare al massimo?
una tabella x utenti, annunci e immobili bastano?
(dove l'id dell'utente è chiave esterna dell'annuncio e l'id dell'annuncio è chiave esterna dell'immobile)

poi i raggruppamenti che nel link qui sopra vengono spiegati x MySQL sono da fare nello stesso modo x PostgreSQL? (è meglio usare MySQL rispetto a PostgreSQL?)
i raggruppamenti alla fine non sono viste? se no qual'è la differenza?

Ciao a tutti! Mi aggiungo anche io...

Per la vicinanza geografica credo ci si debba basare su un punto, perchè se io ho come raggruppamento gli immobili che sono a 10km l'uno dall'altro (con il metodo suggerito da number15), avendo una sufficiente densità di immobili avrei che tutti gli immobili sono nello stesso cluster! Ad esempio se il sito si occupa di vendere case in lombardia, avendo una casa a milano, una a sesto, una a monza, una a lissone ecc... avrei che tutti questi annunci sono nello stesso cluster perchè messi in quest'ordine sarebbero ognuno entro 10km all'altro. A lato pratico questa funzione sarebbe inutile, se io sto cercando una casa a milano non mi va bene una a lissone, o sbaglio?

Il problema rimane scegliere il punto di riferimento... il primo annuncio del database? il centro dell'italia? Oppure devo lasciar scegliere all'utente l'origine (magari con un pulsante specifico "cerca nei dintorni" vicino all'annuncio nella pagina web) e poi ricaricare la pagina con l'annuncio scelto in cima e poi tutti gli altri in cascata. Ma questo sarebbe una funzione a livello di php che non influenza minimamente il database. (E aggiungo che mi sembra la soluzione più sensata).

Per gli altri parametri sarebbe più semplice. Ad esempio per la suddivisione in base al contratto io fare una vista che replica la tabella immobile (io ho semparato annuncio e immobile) ma con un ordinamento a livello del campo "contratto" (GROUP BY) Nella visualizzazione scorrerei la tabella e ogni volta che cambia il valore di "contratto" (ma può essere anche un qualsiasi altro parametro, tipo la categoria) stampo una linea nella pagina a segno che cambia il tipo di paramentro.

Ciao marco,
il problema è sempre lo stesso: non si capisce la richiesta!

Come hai giustamente spiegato il primo metodo non ha senso o meglio non ha nessuna utilità nella pratica oltre ad essere di complicatissima realizzazione per me (mi pare che Shaper avesse linkato l'algoritmo da implementare).

Anche scegliere un punto di riferimento fisso non ha molto senso. Se sono a Milano sicuramente non mi interessa cercare gli immobili a 10km da Roma e idem per il viceversa.

L'unico che ha senso è appunto il 'cerca nei dintorni', ma non è una tecnica di cluster.

Io rinnovo il consiglio di chiedere ai prof o di sperare che qualcuno che abbia già discusso il progetto dia delucidazioni su questo punto.

Non mi è chiaro invece cosa vuoi fare per gli immobili.
Anche qua comunque la richiesta è un po' 'fumosa': cosa te ne fai di più viste materializzate!?
Io al max ne creerei una e studierei quali campi indicizzare.

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

Originally posted by thirdmoon030
Io avrei un po di domande a carattere generale sul progetto anche perchè è da un po che l'ho iniziato ma non riesco a venire a capo di alcune cose.

Inizierei dalle tabelle:
bisogna mettere + tabelle possibile o generalizzare al massimo?
una tabella x utenti, annunci e immobili bastano?
(dove l'id dell'utente è chiave esterna dell'annuncio e l'id dell'annuncio è chiave esterna dell'immobile)

poi i raggruppamenti che nel link qui sopra vengono spiegati x MySQL sono da fare nello stesso modo x PostgreSQL? (è meglio usare MySQL rispetto a PostgreSQL?)
i raggruppamenti alla fine non sono viste? se no qual'è la differenza?

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

quante dovrebbero essere le tabelle?
bisogna dividere le tipologie di annunci es affitto e vendita? o le categorie di immobili? es monolocale, bilocale ecc... oppure no?

Il numero di tabelle non so dirtelo, in quanto non ho fatto, ne sto facendo, il progetto.

Prova a guardare nelle pagine indietro che qualcosa si è discusso.

Così su due piedi non so dirti cosa devi dividere.
Prova a fare ed eventualmente postare lo schema ER e poi decidi come implementare il tutto.

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

Originally posted by number15
Ciao marco,
il problema è sempre lo stesso: non si capisce la richiesta!

Come hai giustamente spiegato il primo metodo non ha senso o meglio non ha nessuna utilità nella pratica oltre ad essere di complicatissima realizzazione per me (mi pare che Shaper avesse linkato l'algoritmo da implementare).

Anche scegliere un punto di riferimento fisso non ha molto senso. Se sono a Milano sicuramente non mi interessa cercare gli immobili a 10km da Roma e idem per il viceversa.

L'unico che ha senso è appunto il 'cerca nei dintorni', ma non è una tecnica di cluster.

Io rinnovo il consiglio di chiedere ai prof o di sperare che qualcuno che abbia già discusso il progetto dia delucidazioni su questo punto.

Non mi è chiaro invece cosa vuoi fare per gli immobili.
Anche qua comunque la richiesta è un po' 'fumosa': cosa te ne fai di più viste materializzate!?
Io al max ne creerei una e studierei quali campi indicizzare.

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

Originally posted by marco91
Per le distanze farò come hai detto anche tu, per la città io ho fatto semplicemente nella tabella immobile un campo città, uno latitudine e uno longitudine. All'inizio avevpo creato una tabella città ma mi sembrava inutile per solo due campi in più.

Originally posted by marco91

Ma se uso varchar metterei l'url dell'immagine giusto? Io uso BLOB, anzi il LONGBLOB, giusto per usare un po' il database Ho già preparato la procedura di upload, funziona bene per cui penso terrò questa

Originally posted by marco91

GROUP BY "campo" ASC/DESC fa la funzione di GROUP BY assieme a quella di ORDER BY riferito a quel campo.

Originally posted by marco91

Mi sono accorto che non ho usato nessun trigger, ma sono indispensabili? Perchè a me funziona tutto ugualmente. Anche le stored procedure non le ho usate...

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

Originally posted by number15
Magari però di città ti servono altre informazioni, tipo se fa o meno provincia, in che provincia sta, regione, nazione ecc.



Si, dovresti semplicemente mettere il percorso dell'img (o parte del percorso) e poi salvare l'immagine in una cartella del sito.
Comunque usa pure il BLOB.



In che linguaggio?
Di sicuro non MySQL, ma dubito pure in altri linguaggi.

In ogni caso la GROUP BY raggruppa, quindi se raggruppi per tipologia di contratto avrai come risultato 2 righe, una per affitto e una per vendita.



I trigger servono per modificare il contenuto delle tabelle a seguito di una qualche azione.
Puoi solitamente ottenere lo 'stesso risultato' usando delle query a livello applicativo, ma in un esame di database solitamente sono richiesti.

Riordina per il campo del group by, ma il 'problema' è che raggruppa.

Se tu hai questa tabella
ANNUNCIO(id_annuncio, contratto, id_utente, ecc)
con queste tuple:
1, vendita, 4
2, affitto, 2
3, vendita, 5
4, affitto, 10
5, affitto, 15
6, vendita, 8

La query SELECT * FROM annuncio GROUP BY contratto
restituirà
2, affitto, 2
1, vendita, 4

e non quello che vuoi far tu.


Per le viste materializzate dai un occhio qua: http://blog.fl3x.de/2005/10/26/mate...views-in-mysql/

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

Originally posted by number15
Riordina per il campo del group by, ma il 'problema' è che raggruppa.

Se tu hai questa tabella
ANNUNCIO(id_annuncio, contratto, id_utente, ecc)
con queste tuple:
1, vendita, 4
2, affitto, 2
3, vendita, 5
4, affitto, 10
5, affitto, 15
6, vendita, 8

La query SELECT * FROM annuncio GROUP BY contratto
restituirà
2, affitto, 2
1, vendita, 4

e non quello che vuoi far tu.


Per le viste materializzate dai un occhio qua: http://blog.fl3x.de/2005/10/26/mate...views-in-mysql/

ciao a tutti,
riguardo al discorso dei cluster e criteri di similarità,

io pensavo di fare cosi:

cominciamo dai piu semplici,
se volessi fare un criterio di similarità per metri quadrati.

creo una vista materializzata con codice annuncio e id_annncio
e creo un indice con su id_annuncio.
Indice cluster (con file ordinati) se ne puo avere solo uno per tabella (correggetemi se sbaglio) quindi ha senso
creare una vista materializzata.

quindi nel caso di un database con moltissimi record si risparmierebbe tempo
nella select.


il mio dubbio é che é vero che si risparmia tempo nelle select, pero'
dopo bisogna fare il join tra id_annuncio e l'annuncio,
quindi mi chiedevo se ne valesse la pena

altrimenti si potrebbe fare una view con tutti le colonne che sono nella tabella
degli annunci, (praticamente una copia della tabella) e mettere semplicemente
un indice su mq, ma in questo caso il mantenimento sarebbe più complesso,
e il db peserebbe di più

voi che dite? vi sembrano strade percorribili?

Ciao Paolos,
non ho mai capito cosa volessero i professori quando parlavano di cluster... bisognerebbe sentire i ragazzi che hanno già discusso il progetto.

Il concetto di cluster vero e proprio è la suddivisione di una tabella in più tabelle più piccole.
Quindi per applicare realmente la clusterizzazione potresti creare n tabelle ANNUNCIO divise per range di metratura in cui copi gli annunci.

Ti faccio un esempio:
ANNUNCIO(tabella contenente tutti gli annunci)
ANNUNCIO_0_40(tabella contenente gli annunci con metratura fino a 40mq)
ANNUNCIO_41_60(tabella contenente gli annunci con metratura maggiore di 40mq e minore di 60)
ecc

Tu inserisci normalmente in ANNUNCIO e poi fai un trigger che in base alla metratura copia l'annuncio nella rispettiva tabella ANNUNCIO_X_X.

A questo punto quando nell'applicazione selezioni il filtro di metratura, fai la select sulla tabella contenente quel sottoinsieme di annunci.

Concettualmente il cluster è questo.
Poi puoi decidere di suddividere in tabelle contenenti già altre informazioni che ti servono (andando quindi a fare prima qualche join) (ad esempio diciamo che tu puoi avere una struttura in cui hai diviso gli immobili dagli annunci, quindi quando crei un annuncio per un immobile devi andare prima a controllare la metratura dell'immobile e poi ad inserirlo nella tabella corretta. A questo punto la tabella ANNUNCIO_X_X potrebbe già contenere anche le informazioni che ti servono relative all'immobile)

Gli indici non fanno altro che ottimizzare le ricerche ordinando già le colonne, ma non applicano nessuna 'divisione'.

Ripeto comunque che prima bisognerebbe capire cosa vogliono realmente i prof.

Venendo al tuo esempio cosa intendi con indice cluster? Che DBMS usi?
A cosa ti servirebbe la tabella con id_annuncio e codice annuncio? Che tipo di select ci andresti a fare?

Ovviamente il secondo esempio ha molto più senso, anche se come spiegato sopra non è una tecnica di cluster.

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

ciao number15, grazie mille per la risposta,

un indice clustered (clustered index) é un indice che crea file ordinati,

qui parla della differenza tra clusered e non clustered index
a proposito di sql server, ma immagino sia un concetto comune ai vari dbms
http://www.mssqlcity.com/FAQ/Genera...red_indexes.htm


qui un post riquardo agli indici clustered in postgres
http://stackoverflow.com/questions/...dex-in-postgres

io uso postgres,

niente immaginavo per esempio di avere una vista meterializzata "annunci_mq"
con colonne "id_annuncio" ed "mq" (scusa avevo scritto sbagliato prima),
con indice cluster su mq.

facendo una query tipo:
SELECT * FROM annunci_mq WHERE mq > valore - range AND mq < valore + range ;

recupero gli id dei record simili per metratura in maniera più veloce che
facendo la query normale, in quanto faccio le select su un atributo con indice.

La strada che hai detto te mi pare ragionevole,
però nel progetto diceva anche che l'amministratore (o l'utente)
devono essere in grado di cambiare il range,
el tuo caso come si farebbe? si fa in modo che l'utente
possa specificare se prendere per i dati per es

ANNUNCIO_0_40(tabella contenente gli annunci con metratura fino a 40mq)

o da
ANNUNCIO_0_80(tabella contenente gli annunci con metratura fino a 40mq)


o da
ANNUNCIO_0_120(tabella contenente gli annunci con metratura fino a 40mq)

creando tante tabelle per i tipi di range che si possono scegliere?

Quindi quale sarebbe il grande vantaggio rispetto a mettere un normale indice su mq nella tabella principale?
La ricerca è comunque ottimizzata.

Dando la possibilità di cambiare il range diventa effettivamente un casino. Devi creare nuove tabelle e risuddividere tutti i dati.

Prova a questo link che ho postato altre volte: http://www.stardata.it/le-novita-di-mysql-5-1-186/
Forse parla di ottimizzare il cambiamento di range (non ho il tempo per riguardare ora)

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

ciao,

il vantaggio é semplicemente che la ricerca su un file ordinato é più veloce,

do un occhiata al link che mi hai mandato,

grazie mille

qualcuno saprebbe dirmi come devo istallare apache e php su Lion?

Come si può fare a creare i cluster per la vicinanza geografica?che funzione da inserire in trigger e funzioni si può usare?

come avete questo problema?

Qualcuno ha qualche suggerimento per la scadenza degli annunci? Come faccio a creare un trigger che confronta la data odierna con la data di scadenza di ogni annuncio?

Puoi utilizzare cron oppure usare gli eventi.

Con i trigger non puoi farlo.

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

E se uso Postgres vanno bene lo stesso sia cron che gli eventi?

Cron sicuramente dato che è "semplicemente" uno script che viene eseguito ogni tot tempo in cui vai ad inserire la query che vuoi sia eseguita.
Non dipende dal DBMS.

http://php.html.it/articoli/leggi/2...e-degli-script/

Per Postgres non ho idea se c'è uno scheduler integrato.

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

Originally posted by number15
Cron sicuramente dato che è "semplicemente" uno script che viene eseguito ogni tot tempo in cui vai ad inserire la query che vuoi sia eseguita.
Non dipende dal DBMS.

http://php.html.it/articoli/leggi/2...e-degli-script/

Per Postgres non ho idea se c'è uno scheduler integrato.

Puoi fare anche come dici tu, ma non è molto ottimizzato.

Io solitamente creo un campo enum 'is_active, che setto a N alla scadenza dell'informazione attraverso lo scheduler.
Quindi li disattivi, non li cancelli.

Nelle query poi ti basterà fare where is_active = 'Y'

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

Io nella mia tabella annuncio ho i due campi "data_pubbl" e "data_scadenza".. Ma quando faccio la ricerca come faccio a mettere la condizione...
SELECT *
FROM annuncio
WHERE " la data di scadenza non ha superato la data odierna"
???

Per Mysql e Postgresql è now()
data_scadenza < now()

In Oracle si usa sysdate
data_scadenza < sysdate

.

.

Non c'è nessuna soluzione diversa dallo scheduler? Mi sembra assurdo che per un progetto del genere (con 2 lezioni del cavolo sul php, e senza aver mai sentito parlare di pgAgent, cron, eventi ecc) ci si debba scervellare in questo modo. Per ora ho aggiunto un campo boolean alla tabella annuncio cosi quando faccio la ricerca ho il controllo WHERE attivo = TRUE. Ora devo solo capire come fare per settare il campo attivo a FALSE quando la data di scadenza supera la data odierna..

Puoi usar la soluzione di aPiso che funziona tranquillamente.

Per far quello che volevi fare tu serve per forza uno scheduler

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

Senza scheduler e con la colonna aggiuntiva "attivo" (boolean) posso limitare la ricerca ad annunci non scaduti..La soluzione di aPiso sarebbe questa giusto? Ma comunque non risolve il problema..Se il mio annuncio x scade oggi, domani quando accedo al database il campo attivo dell'annuncio x dovrà essersi settato automaticamente a FALSE...quindi se non ho capito male mi tocca capire come funziona questo benedetto scheduler

No, questa è la mia

La sua è di fare la query con where data_di_scadenza < now()

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

Scusa la mia ignoranza ma devo concludere questa dannata cosa della data Ora che ho il mio campo 'attivo', per settarlo automaticamente ho bisogno dello scheduler perchè non posso farlo via trigger giusto? Neanche magari con un trigger before insert or update or delete?

PS: ma cron è solo per Linux? Io uso windows

No, con i trigger non risolvi.
I trigger si attivano su una qualche azione, non a tempo.
Quindi se tu non hai azioni, non puoi aggiornare lo stato degli annunci.

Quindi le opzioni sono 2:
1) usare il campo attivo, e utilizzare uno scheduler per aggiornarlo (che sia cron o quello di postgres)
2) non usare il campo attivo e nelle query aggiungi il controllo che la data d scadenza sia minore della data odierna.

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

Originally posted by pintu
PS: ma cron è solo per Linux? Io uso windows

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

Si ho usato la seconda alla fine..quando eseguo la ricerca di un immobile faccio prima un UPDATE della tabella annuncio.. se data_scadenza > now() allora 'attivo' = FALSE, poi eseguo la ricerca. Grazie comunque per la pazienza Posso chiederti un altro aiuto?
Nella tabella annuncio io ho i due attributi data_pubbl e data_scadenza di tipo DATE. Io però vorrei che l'utente della mia applicazione inserisca solo la data di pubblicazione e che la data_scadenza sia calcolata automaticamente, tipo 30 giorni dopo la data_pubbl...come posso fare?

Il problema è che usi postgres e non ho idea delle funzioni che abbia.

Per myslq son queste: http://dev.mysql.com/doc/refman/5.5...-functions.html

Devi cercare le equivalenti per postgres.
Quella che ti serve dovrebbe essere la funzione DATE_ADD()

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

Grazie ho risolto la cosa delle date! Come faccio a inserire delle immagini all'interno del database? (Postgres)

Metti il percorso in un campo text e lo usi come img src nel'html

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

Non capisco perchè non funziona

<img src="C:\Program Files\PostgreSQL\EnterpriseDB-Apache\Php\apache\www\NEWS_1336368281_TUTTO.jpg" />

quando carico la pagina contenente l'immagine non la visualizza!

niente risolto

scusate io non ho capito solo una cosa per i cluster... mettiamo ad esempio che io voglia attuare il criterio di similarità geografica.
Quindi se questo criterio è selezionato come il criterio attivo quando seleziono un annuncio devo mostrare gli annunci simili.
Ma io questi annunci sarei andato a pigliarli con una funzione, mentre da quel che leggo vanno messi in una qualche vista materializzata e aggiornati man mano... ma in questo modo dovrei creare una vista materializzata per ogni annuncio, che contenga gli annunci che gli stanno vicini!! mi sembra una cosa completamente folle, uno si fa un sacco di problemi in fase concettuale per una tabella in più o in meno, e poi a fronte di un numero potenziale di 1 milione di annunci finisco per creare un milione di tabelle? Mi sembra talmente impossibile che penso davvero di aver interpretato male io la consegna, qualcuno mi può per cortesia fare un po' di chiarezza?

Io sono nella tua stessa situazione. Lasciando stare che non ho idea di come implementare il criterio di similarità geografica, mi sembra comunque una richiesta assurda (soprattutto rispetto alle cose spiegate a lezione) e esposta in modo tutt'altro che chiaro.. Non so se il ragionamento che hai fatto tu sia simile al mio..ti spiego: inserisco il primo annuncio, mettiamo che si trovi a milano, e creo vista che contiene questo annuncio. Al secondo inserimento, se l'annuncio è "simile" al primo (10 km nel raggio di milano) lo inserisco nella stessa vista, altrimenti creo un'altra vista e lo inserisco li... e cosi via! Ho compreso bene?

Ciao a tutti,

anche io sono alle prese con il progetto, lo sto cercando di fare per la consegna di luglio e ho ancora un bel pò di dubbi...

1. Cosa si intende per viste materializzate? Se ho capito bene sono tabelle normali che hanno le stesse (o quasi) colonne di un'altra tabella (e che non è vista), all'interno del quale, attraverso dei trigger, vengono inseriti/rimossi/aggiornati i record all'interno .. Voi come le avete fatte?

2. Questa cosa dei cluster mi lascia ancora molto confuso: io credo che sia da sviluppare con l'idea "gli annunci vicini a un dato annuncio", quindi il punto di partenza sono le coordinate di un annuncio dato in parametro... detto questo, come è possibile strutturare qualcosa di questo tipo su un database??? l'unica cosa (assurda) che mi viene in mente è una tabella fatta ad esempio da due colonne, entrambe FK di annunci, dove ogni coppia di id indica annunci vicini.... come avete fatto voi?

@aPiso e @pintu ho gli stessi indentici dubbi vostri (meno male, pensavo di essere l'unico), avete risolto in qualche modo? qualcuno è riuscito a parlare con il professore per capire che diavolo vuole che si realizzi?

Ciao e grazie!

@aPiso non ho la minima idea di cosa tratti il progetto ma penso che sia giusto creare e mantenere le viste materializzate visto che in un sito realmente operativo la mancanza di cache si sente e come. Quindi anche se all'inizio costa un po crederci, queste sono utili tanto quanto la progettazione del DB stesso.
Cmq non si rischia di creare 1Kviste per 1Kannunci. Se clusterizzato questo creera viste solo per i cluster selezionati (da aggiornare con i nuovi dati). Salutissimi, e se hai bisogno di una mano chiedimi pure...

@Shady90 ripassa i comandi base dei DBMS per le viste. Per i cluster pensa ai filti che usi ad es. su Booking per selezionare un sottoinsieme di alberghi... se la vista c'è allora vanno solo recuperati i dati, altrimenti il DBMS si deve fare tutta l'esecuzione della query e poi passarti i dati.

Giusto?!

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

Scusate una cosa...nel testo del progetto si parla di cluster, ma in pratica questi cluster saranno da implementare tramite delle viste no?? Oppure si parla di indici, clusterizzazione di tabelle ecc?? No perchè non mi sembra che al laboratorio queste cose sono state fatte...

@CowBoy in che senso "ripassa i comandi base dei DBMS per le viste" ? è sbagliato quello che ho detto sulle viste materializzate?

mah comunque per me continua a non aver senso creare una vista per ogni annuncio per clusterizzare gli annunci vicini..

Si parla di cluster come termine generico di raggrupamento logico o gruppo di unità simili... uno dei tanti termini inglesi presenti nell'informatica che ha molteplici applicazioni (non solo nei DBMS).

Viste materializzate:
Viste (il risultato dell'esecuzione di una query) salvate sotto forma di struttra dati.
http://wiki.postgresql.org/wiki/Mat...Views_GSoC_2010
http://tech.jonathangardner.net/wik...erialized_Views
http://www.revsys.com/blog/2006/jan...-in-postgresql/

Importante manterere aggiornate tali strutture dati in modo opportuno. Le strutture servono da cache all'applicazione per evitare di eseguire ogni volta query anche molto lunghe o su una quantità di dati importante.
Bene aggiungerle con i trigger, ma magari pensare anche a una soluzione ad hoc per dare robustezza alla struttura (tipo ogni settimana/giorno/mese/ect. elimino la cache ed eseguo la query per ricreare le strutture dati)

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

scusate, cerchiamo di capire una cosa alla volta..

lasciando un attimo da parte il discorso dei cluster, la parte più semplice sulle viste materializzate:
"Lo studente realizzi opportune viste materializzate per i criteri di selezione che ritiene maggiormente utilizzati. E' pertanto necessario realizzare gli opportuni trigger che mantengano aggiornate tali viste in relazione all'inserimento o alla modica di annunci."

quello che occorre fare è creare dei trigger che ad ogni insert/update/delete crei/aggiorni delle tabelle (temporanee, ma tabelle vere e proprie) in cui inserisce/modifica/rimuove dei record "COPIA" di quelli che si stanno inserendo/modificando .. qualcosa del genere?

faccio un esempio:
- inserisco un annuncio nella tabella ANNUNCI, l'annuncio è della tipologia "vendita"
- il trigger interviene nella insert, crea se non esiste già una tabella tipo "ANNUNCI_VENDITA" e inserisce al suo interno un record identico (o quasi) a quello che è stato inserito (dico quasi perchè porto solo le colonne che poi realmente vengono interrogati cercando gli annunci)

un altro esempio:
- aggiorno un annuncio nella tabella ANNUNCI, cambiando la tipologia da "vendita" ad "affitto"
- il trigger rimuove il record relativo a quell'annuncio dalla tabella "ANNUNCI_VENDITA" e lo inserisce in "ANNUNCI_AFFITTO"


... può andare bene?

Ottimo use case... allora ci stiamo capendo. Avanti così!

P.S: Meglio avere già pronte le tabelle, tanto conosci a priori i criteri di selezione.

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

.... ovvero??

utilizzare istruzioni apposite come CREATE MATERIALIZED VIEW non credo sia quello che voglia vedere, l'idea è probabilmente quella di implementare noi delle viste materializzate, non usare strumenti già gestiti dal DBMS ("è pertanto necessario realizzare gli opportuni trigger che .....")

se non fosse così nulla avrebbe senso, perchè sappiamo entrambi che i DBMS gestiscono automaticamente la cache delle viste scegliendo se rieseguire la query della vista oppure interrogare una cache dell'ultima interrogazione ..

Giusto e capisco cosa vuoi dire. Cmq evito adesso di sbandare e uscire fuori argomento.

Chiaro è che l'importanza maggiore in questa parte del progetto non è capire se e come hai fatto la struttura dati, se non capire quando e dove attivi i trigger. Insomma, il loro utilizzo.

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

Ok, grazie del supporto CowBoy.

Sto implementando come ho scritto sopra per quanto riguarda le viste materializzate che velocizzano la ricerca.
Sono ancora un pò perplesso invece per la realizzazione dei cluster che dividono gli annunci per similiarità .... se non ne vengo a capo la faccio lato web con delle query mirate e non lato db!

Se qualcuno ha buone idee ci faccia sapere!!

"L'amministratore può cambiare la visualizzazione in cluster selezionando un diverso criterio di similarità tra quelli supportati dall'applicazione."

Se io ho il criterio di similarità geografica e un ipotetico criterio di similarità sulla base del prezzo come posso scegliere tra uno dei due lato DB?? Dato che questi due criteri saranno implementati tramite funzioni non posso scegliere a priori quale utilizzare...

Originally posted by pintu
"L'amministratore può cambiare la visualizzazione in cluster selezionando un diverso criterio di similarità tra quelli supportati dall'applicazione."

Se io ho il criterio di similarità geografica e un ipotetico criterio di similarità sulla base del prezzo come posso scegliere tra uno dei due lato DB?? Dato che questi due criteri saranno implementati tramite funzioni non posso scegliere a priori quale utilizzare...

Potrebbe essere una soluzione! Anche perchè poi si può ottenere lo stesso risultato lato Web con una semplice submit che esegue l'update!

Se mi illumino con qualche altra soluzione ti aggiorno

scusa pintu, alla fine tu come hai fatto i cluster per vicinanza?

ci sto lavorando ancora non ho fatto niente! A parte l'idea che avevo postato qualche commento più su non sono andato avanti!

Qualcuno sa se si può fare una cosa del genere?

CREATE OR REPLACE FUNCTION prova(varchar(20)) RETURNS VOID AS $$

BEGIN
CREATE VIEW vista($1) AS
SELECT attributo
FROM tabella
WHERE condizione

RETURN;

END;

$$ language plpgsql;


In pratica voglio una funzione che prende in input un varchar(20) e crei una tabella il cui nome sia: vista('valore in input').
E' possibile?? Ho fatto diverse prove ma non ottengo risultati, forse però sbaglio qualcosa nella sinstassi.