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

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

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

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

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.

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

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

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?

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.

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]

??

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

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

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 :D

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.

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!

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

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?

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

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

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.

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.

Originally posted by number15
Sì, ho capito, ma non è un cluster :-D
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.

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/

Originally posted by Shaper

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

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?

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

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.

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

code:

SELECT *
FROM vista

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

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

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.