aiutino con progettazione database

Salve,

sto progettando un database e vorrei chiedere un chiarimento su sta cosa :

ho una tabella announces:

anid     INT(11)                     id annuncio
usid    INT(11)                 id autore
location    INT(11)                 id località
genre    INT(11)                 id tipologia
prices    INT(11)                 id tabella prezzi
flags    SET(*FLG_SET)                   FLG_SET: offerta,novità,lastminute
available    ENUM('y','n')              n    è ancora disponibile?
moderated    ENUM('y','n')              n    è visibile e moderato?
votes    INT(11)                   numero di click per la classifica

e vorrei collegare ad ogni annuncio ( tramite il suo id ) ad una tabella prezzi

tenendo conto che non conosco a priori il numero di prezzi ed il loro valore

stavo pensando ad un valido e flessibile stratagemma per inserire ed avere i prezzi nel database collegati all'annuncio...in questo modo però ( utilizzando il database ) ho un numero di prezzi limitati, ammettiamo a 16, quindi se modifico il db devo modificare la pagina che mostra i risultati, a meno che non crei una funzione ad hoc per mostrare un determinato numero di righe e colonne per una tabella in modo da inserire i prezzi in modo più flessibile... ma l'attenzione mi ricade sulla flessibilità del database ... dovrei avere tanti record con allegato l'id dell'annuncio che contengono i prezzi per avere un numero "infinito" di prezzi per annuncio.

Questa a me sembra la soluzione più adeguata, ma qui iniziamo a parlare di prestazioni , questa cosa ( id annunci e tanti record in un'altra tabella collegati a quell'annuncio ) la utilizzo già per collegare immagini a quello stesso annuncio, faccio un esempio per chiarire un attimino:

id annuncio : 1

tabella immagini:

id immagine : 1

id annuncio : 1

-----------------

id immagine 10

id annuncio 1

-----------------

altre 15 immagini ad annuncio con id 1

quindi dovrei , con un join, prendere prima tutte le immagini collegate all'annuncio ID e poi prendere sempre con un altro join ( si possono fare più join nella stessa query vero?? ) estrarre i prezzi e mostrarli nella funzione ad-hoc contanto il numero di questi e creando una tabella contenente come modalità il periodo ( che si trova assieme al prezzo ) e il prezzo stesso.

se non sono stato chiaro ditemelo che cerco di spiegarmi meglio  :2funny:, scusate ancora se si capisce poco... come al solito dimentico quello che scrivo rigo per rigo ( ho poca ram :) ) :buck:

 :bye:

PS: Gianni lo so che mi sono dato la risposta da solo mentre scrivevo, me lo sento, ma dimmi, più che come fare, se questo metodo è "corretto" o se ce ne sono altri migliori e soprattutto più performanti :bye:

inviato 10 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

c'è un nesso tra le immagini e i prezzi? Da quello che ho letto mi sembra di no ma ti chiedo conferma.

Se non c'è nessun legame allora devi fare 2 query, ciascuna con un unico join, per estrarre tutte le immagini (prima query) e tutti i prezzi (seconda query)

Se il numero dei proezzi non è noto a priori l'unica soluzione è quella che hai individuato.

 :bye:

risposto 10 anni fa
Gianni Tomasicchio
X 0 X

no non ci sono legami tra immagini e prezzi ma tra immagini / annunci e prezzi / annunci

diciamo che c'è una relazione n:1 cioè tanti prezzi collegati ad un annuncio e la stessa cosa vale per le immagini... ma le immagini le ho nominate solo per dirti che c'è lo stesso ragionamento applicato anche per legare le immagini all'annuncio :D ma non hanno nulla a che fare con i prezzi , era solo per sapere se due di questi metodi possono essere eccessivamente lenti

:bye:

risposto 10 anni fa
Andrea Turso
Andrea Turso
86
X 0 X

questi metodi sono veloci  ;)

risposto 10 anni fa
Gianni Tomasicchio
X 0 X

ah ok good, io mi stavo facendo tanti problemi :D

grazie :bye:

risposto 10 anni fa
Andrea Turso
Andrea Turso
86
X 0 X
Effettua l'accesso o registrati per rispondere a questa domanda