 | |
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 |
Progetto Basi 2011/2012
Clicca QUI per vedere il messaggio nel forum |
| marco91 |
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! :D 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 |
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 |
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. |
| paolos |
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 |
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) |
| paolos |
ciao,
il vantaggio é semplicemente che la ricerca su un file ordinato é più veloce,
do un occhiata al link che mi hai mandato,
grazie mille |
| gionavisi |
| qualcuno saprebbe dirmi come devo istallare apache e php su Lion? |
| gionavisi |
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? |
| pintu |
| 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? |
| number15 |
Puoi utilizzare cron oppure usare gli eventi.
Con i trigger non puoi farlo. |
| pintu |
| E se uso Postgres vanno bene lo stesso sia cron che gli eventi? |
| 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. |
| aPiso |
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.
C'è pgAgent se proprio vuoi fare così... ma non è più facile calcolare semplicemente la data di scadenza in inserimento, metterla in una colonna, e con la funzione cerca cercare solo gli annunci non scaduti?
Alla fine la consegna del progetto è di non visualizzare gli annunci, non cancellarli, e almeno l'utente ha tutti i suoi annunci nel profilo, anche quelli scaduti!!
Comunque: http://www.pgadmin.org/docs/1.4/pgagent.html |
| number15 |
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' |
| pintu |
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"
??? |
| zack1988 |
Per Mysql e Postgresql è now()
data_scadenza < now()
In Oracle si usa sysdate
data_scadenza < sysdate |
| pintu |
| 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.. |
| number15 |
Puoi usar la soluzione di aPiso che funziona tranquillamente.
Per far quello che volevi fare tu serve per forza uno scheduler |
| pintu |
| 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 :D |
| number15 |
No, questa è la mia :-D
La sua è di fare la query con where data_di_scadenza < now() |
| pintu |
| Scusa la mia ignoranza ma devo concludere questa dannata cosa della data :D 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? |
| pintu |
| PS: ma cron è solo per Linux? Io uso windows |
| number15 |
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. |
| number15 |
Originally posted by pintu
PS: ma cron è solo per Linux? Io uso windows
Si, solo linux.
Non conosco alternative...
Prova comunque lo scheduler di postgres, ha anche più senso per un esame di db.
Se non vuoi impazzire, utilizza l'altra soluzione. |
| pintu |
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? |
| pintu |
| Grazie ho risolto la cosa delle date! Come faccio a inserire delle immagini all'interno del database? (Postgres) |
| number15 |
| Metti il percorso in un campo text e lo usi come img src nel'html |
| pintu |
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! |
| aPiso |
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? |
| pintu |
| 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? |
| Shady90 |
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! |
| CowBoy |
@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?! |
| pintu |
| 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... |
| Shady90 |
@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.. |
| CowBoy |
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) |
| Shady90 |
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? |
| CowBoy |
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. |
| Shady90 |
.... 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 .. |
| CowBoy |
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. |
| Shady90 |
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!! :D |
| 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... |
| Shady90 |
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...
io stavo pensando a una tabella "Amministrazione", con tipo due colonne "chiave" "valore", dove una delle chiavi serve ad impostare quale criterio usare.
nelle funzioni quando ne ho bisogno interrogo la tabella, dall'applicazione invece per cambiare faccio un update sulla tabella.
non mi è venuto in mente nient'altro.. |
| pintu |
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 :D |
| Shady90 |
| scusa pintu, alla fine tu come hai fatto i cluster per vicinanza? |
| pintu |
| ci sto lavorando ancora non ho fatto niente! A parte l'idea che avevo postato qualche commento più su non sono andato avanti! |
| pintu |
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. |
| Shady90 |
vuoi creare una vista che si chiami vista('PARAMETRO') ??
io farei una cosa tipo VISTA_PARAMETRO, non so se puoi mettere parentesi e apici nel nome di una vista ..
io comunque non usando il plpgsql non saprei aiutarti, sto facendo tutto in sql server con le stored procedure |
| pintu |
| In teoria l'idea era quella, ma da quanto ho capito non si può fare. Per l'implementazione dei cluster volevo creare una vista diversa per ogni range di valori del criterio di similarità...mi sa però che l'idea è sbagliata..Non so proprio come fare! |
| Ivand |
| Per consegnare il progetto bisogna iscriversi all'appello? |
| Shady90 |
l'idea dei cluster fatte con viste di annunci simili in teoria è corretta, però se ci rifletti già non può andar bene per la vicinanza geografica: metti di avere annuncio A a 9km da B e annuncio C a 8km da B ma a 18 da A (messi in linea retta) ... bè in questo caso A è in cluster con B, B è in cluster con C, ma A e C devono essere in cluster diversi ... come puoi fare con una vista???
è più complicata di quanto pensassi .. se qualcuno ha buone idee per favore si faccia sentire! |
| Shady90 |
| qualcuno ha consegnato all'appello del 21? quando farà la discussione del progetto? |
| pintu |
| Qualcuno di voi che usa postgres ha usato il tipo SERIAL per qualche attributo? Ho una tabella A con chiave primaria id di tipo SERIAL. L'attributo ref_id di una tabella B, fa riferimento a id. ref_id devo dichiararlo per forza di tipo SERIAL?? |
| Shady90 |
| pintu io uso sql server, ma ho anche io gli id che fanno da chiave primaria in tutte le tabelle ti tipo serial: le chiavi esterne non devono essere assolutamente serial, altrimenti sarebbero autoincrement anche quelle; io le ho fatte numeric(18,0) not null |
| Shady90 |
per la clusterizzazione degli annunci, secondo voi qual'è migliore tra queste 2 alternative?
1. per ogni annuncio inserito creo una vista materializzata (una tabella temporanea) con una sola colonna in cui inserisco gli annunci a 10 km di distanza
2. creo una sola tabella con 2 colonne id_annuncio in cui ogni coppia rappresenta 2 annunci di immobili vicini a 10km
in entrambi i casi ho però il problema di ridondanza dati, ovvero segno che l'annuncio x è vicino a quello y e in un altro posto che l'annuncio y è vicino a quello x ......
EDIT: opterò per la 2 alla fine! mi viene anche comodo e semplice il trigger di insert update e delete |
| pintu |
| per la consegna del progetto bisogna iscriversi al sifa?? |
| ste89 |
Ciao a tutti,
Anche io sto realizzando il progetto di basi di dati, sto ragionando ora sulla ricerca, per poter rendere la ricerca migliore è necessario usare le viste materializzate e trigger.
Io ho iniziato, ma mi sta sorgendo un dubbio.
Ricapitolo un attimo quello che ho capito riguardo alle viste materializzate con PostgreSQL:
1) Per creare le viste materializzate devo creare una nuova tabella con la sintassi classi CREATE TABLE nomeTabella (------); con gli stessi attributi della tabella "originaria".
2) Creare una function che ritorna un trigger (....RETURNS TRIGGER ....)
3) Creare il trigger vero e proprio.
In questo modo ogni volta che inserirò un dato nella tabella "originaria" il trigger lo inserirà anche nella tabella (vista materializzata).
Ho detto una serie infinita di cazzate? o il mio procedimento è corretto?
E in secondo luogo, in questo modo non mi vengo a trovare una bd con un alto numero di tabelle e molte per contenere gli stessi dati?
Spero che qualcuno possa chiarire i miei dubbi, un ringraziamento a tutti,
ciao, Stefano. |
| thirdmoon030 |
Ciao stefano, anche io sono un po incasinato con questo progetto per colpa delle viste materializzate, tra l'altro non ho neanche seguito il corso e per quanto vedo anche nelle slide(e nel libro) l'argomento è poco esaminato.
Io avevo già consegnato un progetto (fatto male) a febbraio e mi è stato detto che le viste materializzate sono obbligatorie per la buona considerazione del progetto.
(Anche i cluster vanno implementati come viste materializzate)
Sinceramente però sfogliando un po il web mi sn trovato spiazzato perchè ho trovato soluzioni per postgres che lasciano molto a desiderare, o per lo meno sono di una complessità che sicuramente non è stata trattata nelle slide(se avete slide o appunti trattati a lezione fatemi sapere).
L'unica cosa che ho trovato (tra l'altro su questo forum) è http://tech.jonathangardner.net/wik...erialized_Views anche se è un po complesso come metodo suppongo vogliano proprio questo. |
| ste89 |
Ciao anche io cercando nel web avevo trovato quella pagina, alla fine io ho fatto come scritto nel mio post precedente, ho creato le tabelle e le functions con i trigger per fare in modo che le tabelle create come "viste materializzate" siano aggiornate subito dopo l'inserimento.
Ciao, Stefano. |
| ste89 |
Ciao anche io cercando nel web avevo trovato quella pagina, alla fine io ho fatto come scritto nel mio post precedente, ho creato le tabelle e le functions con i trigger per fare in modo che le tabelle create come "viste materializzate" siano aggiornate subito dopo l'inserimento.
Ciao, Stefano. |
| Shady90 |
@pintu: si bisogna iscriversi al sifa! io ho scritto una mail spiegando che non devo fare lo scritto ma solo consegnare il progetto, mi è stato detto che l'iscrizione è comunque necessaria
@ste89: io ho fatto proprio come hai detto tu, le viste materializzate le ho fatte con delle create di tabelle identiche a quelle originali con gli stessi dati dentro (spartiti nelle varie diverse viste); per i cluster però non ho fatto nello stesso modo, anche perchè secondo me è impossibile.. ho fatto delle tabelle di associazione: 2 colonne entrambi chiavi esterne ad annuncio dove ogni record indica "annunci simili" |
| Shady90 |
| Per la cronaca, alla fine a me è andata bene, le scelte erano tutte corrette. Mi ha tolto un punto però per il diagramma ER che non era fatto secondo gli standard.... Mah vabè, mi ha dato +2 e va bene così :) |
| gz706450 |
| come avete risolto il fatto che i criteri di selezione devono poter essere combinati fra loro, cioe` che sia possibile filtrare gli annunci in base al numero locali e contemporaneamente alla metratura e/o alla citta` di interesse?? |
| mauro21 |
alla fine la parte sui cluster per distanza l'ho risolta implementando l'algoritmo k-means (casino!!!!)
x i criteri di selezione combinati in pratica ho aggiunto dal php dei pezzi alla query sql
Mi spiego meglio:
la query base è questa
$query= " SELECT i.`Id-Immobile`, a.`Titolo`, a.`Descrizione`, a.`Contratto`,a.`Data_Pubblicazione`, a.`Data_Scadenza`, i.`Citta`, i.`Indirizzo`, i.`Metratura`,i.`Num_Locali`, c.`Nome_Categoria`, a.`Prezzo`, u.`Mail`
FROM Immobile i, Annuncio a, Utente u, Categoria c
WHERE i.`Id-Immobile` = a.`Id-Immobile` AND u.`Id-Utente`=a.`Id-Utente` AND i.`Id-Categoria` = c.`Id-Categoria` AND
CURDATE() between a.`Data_Pubblicazione` AND a.`Data_Scadenza`";
e poi, se x esempio viene selezionato come criterio prezzo (es prezzo<1000), aggiungo alla stringa della query un'altra stringa (in questo caso la stringa $uno, dove $segno è <,> o = e $prezzo è il prezzo inserito)
if ($prezzo!=0){
$uno=" AND a.`Prezzo` $segno $prezzo ";
$query=$query.$uno;
}
spero di esser stato chiaro |
|
|
|
|
