number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

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

number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

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?

Devi rispettare il più possibile la 3NF per cui 3 tabelle in tutto sicuramente non bastano

Per PostgreSQL non so aiutarti, non l'ho mai utilizzato.

Ora non so a che link ti riferisci, se è quello per la spiegazione dei cluster lascialo perdere per ora che è piuttosto complesso e dubito sia richiesto ai fini del progetto.

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

thirdmoon030

User info:

Registered: Nov 2008
Posts: 33 (0.01 al dì)
Location:
Corso:
Anno:
Time Online: 13:22:39 [...]
Status: Offline

Post actions:

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?

number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

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

marco91

User info:

Registered: Feb 2012
Posts: 6 (0.00 al dì)
Location:
Corso: Informatica
Anno: 2
Time Online: 0:36:51 [...]
Status: Offline

Post actions:

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.

number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

Ad occhio direi che ti manca una tabella città, il cui id diventa fk in immobile.
Per la tabella files non utilizzerei un campo blob, ma un normale varchar (guarda il topic sotto a questo).

Poi mancano le tabelle che si creano dalle relazioni n a n, tipo tra immobile e files o tra annuncio e files (in base a cosa vuoi associarle).

Comunque andrebbe visto lo schema ER ed il relazionale completo.

GROUP BY non fa quello che vuoi. Non è che ti stai confondendo con ORDER BY?

Per i cluster ti ripeto non so cosa voglia. Dubito però intenda una semplice vista. Una vista è semplicemente una query. Quando operi sulla vista, semplcimente viene prima eseguita la query della vista e poi eseguita la query sulla vista.

Quindi una query del tipo

code:
SELECT (campi utili)
FROM (tabelle join)
ORDER BY contratto

code:

SELECT *
FROM vista

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

Last edited by number15 on 09-02-2012 at 15:05

marco91

User info:

Registered: Feb 2012
Posts: 6 (0.00 al dì)
Location:
Corso: Informatica
Anno: 2
Time Online: 0:36:51 [...]
Status: Offline

Post actions:

Originally posted by number15
Ad occhio direi che ti manca una tabella città, il cui id diventa fk in immobile.
Per la tabella files non utilizzerei un campo blob, ma un normale varchar (guarda il topic sotto a questo).

Poi mancano le tabelle che si creano dalle relazioni n a n, tipo tra immobile e files o tra annuncio e files (in base a cosa vuoi associarle).

Comunque andrebbe visto lo schema ER ed il relazionale completo.

GROUP BY non fa quello che vuoi. Non è che ti stai confondendo con ORDER BY?

Per i cluster ti ripeto non so cosa voglia. Dubito però intenda una semplice vista. Una vista è semplicemente una query. Quando operi sulla vista, semplcimente viene prima eseguita la query della vista e poi eseguita la query sulla vista.

Quindi una query del tipo

code:
SELECT (campi utili)
FROM (tabelle join)
ORDER BY contratto

è identica

code:

SELECT *
FROM vista

dove vista è quella sopra.
Non cambia niente.

Come minimo vorrà delle viste materializzate.

Concordo che non abbia senso per le distanze.
Io metterei dei campi lat e lon in immobile e poi mostrerei gli immobili che distano xkm dal punto selezionato (ho postato una funzione che utilizzo per trasformare in km le distanze tra coordinate).

Conscio del fatto che lei parla di tutt'altro però.

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

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

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

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

number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

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

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

marco91

User info:

Registered: Feb 2012
Posts: 6 (0.00 al dì)
Location:
Corso: Informatica
Anno: 2
Time Online: 0:36:51 [...]
Status: Offline

Post actions:

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.

Bo a me il GROUP BY riordina anche

I trigger ho già trovato dove inserirli, mi ero dimenticato delle viste materializzate (che su MySQL non sono supportate) per cui devo gestirle manualmente!

number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

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

marco91

User info:

Registered: Feb 2012
Posts: 6 (0.00 al dì)
Location:
Corso: Informatica
Anno: 2
Time Online: 0:36:51 [...]
Status: Offline

Post actions:

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/

Già infatti faceva casini! Ora ho sistemato. Per le viste, visto materializzate che non sono supportate da mysql, ne ho creata una io facendo una tabella e poi mantenendola aggiornata tramite vari trigger.

Ora devo solo finire i manuali, speriamo solo che il progetto le vada bene dopo 20 giorni di lavoro ininterrotto!!

paolos

User info:

Registered: Mar 2011
Posts: 13 (0.00 al dì)
Location:
Corso:
Anno:
Time Online: 7:25:09: [...]
Status: Offline

Post actions:

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?

number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

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

paolos

User info:

Registered: Mar 2011
Posts: 13 (0.00 al dì)
Location:
Corso:
Anno:
Time Online: 7:25:09: [...]
Status: Offline

Post actions:

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?

number15

User info:

Registered: Nov 2005
Posts: 652 (0.10 al dì)
Location:
Corso:
Anno:
Time Online: 121 Days, 13:57:11 [...]
Status: Offline

Post actions:

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