Re: consiglio gestione db
Von: RedWiz (redwiz@inwind.it) [Profil]
Datum: 04.07.2008 19:27
Message-ID: <pan.2008.07.04.17.27.05.527628@inwind.it>
Newsgroup: it.comp.os.linux.sys
Datum: 04.07.2008 19:27
Message-ID: <pan.2008.07.04.17.27.05.527628@inwind.it>
Newsgroup: it.comp.os.linux.sys
> La dimensione delle tabelle in gioco è solo uno degli aspetti. > Non è proprio semplice enunciare delle regole assolute, mi sto occupando > di un progetto (ancora in fase embrionale) che calcoli i percorsi di > join e i filtri in maniera automatica data una serie di regole e questa > è la parte più pesante, al limite della telepatia :-) eh da quello che mi scrivi sembra proprio così > Comunque, bisogna prima stabilire un percorso di join tra le tabelle in > gioco. In alcuni casi (per tabelle molto piccole, quando si può > ricercare per chiave primaria e il risultato finale è comunque > limitato) si può decidere di utilizzare anche subquery. > > Comunque ipotizziamo che le tabelle A B e C siano collegate in questo > modo: > > A -> B -> C in verità le mie sono che la tabella A ha FK sia in B che in C, ma B e C tra loro sono scollegate, anche se (ad occhio) il prodotto cartesiano con una join multipla alla fine è lo stesso, quindi anche la criticità delle query... > Il discorso cambia ulteriormente con le outer join e se utilizzi > funzioni di aggregazione (sum, count, ecc) o direttive di ordinamento. molto probabile che accada! > Si potrebbe istruire un intero corso. da quello che scrivi,direi proprio di sì > Come avevo indicato nell'altro mio post, bisogna utilizzare la direttiva > explain per pianificare le query. infatti, ne terro' conto in fase di prova con dati fittizzi (e ne mettero' tanti) > Uno dei "trucchi" è quello di salvare i dati più destrutturati > possibile (senza esagerare, naturalmente). sì, qua c'ero. > Anche qui il progetto di uno > schema non è affatto una cosa banale (a meno che l'applicazione che ne > fa uso non sia banale) l'applicazione è un semplice aggregatore di informazioni (bot) che le salva nel db (no modifica alle info precedenti) l'altro lato dell'applicazione è la consultazione di tali informazioni senza la possibilità di modifica/cancellazione delle stesse > Considera, inoltre, che grandi big come Google non usano dbms > relazionali ... ah... > >> grazie mille, ne faro' tesoro! > > Prego e spero di non aver creato confusione. in una parola , "disarmante" :) c'è da studiare , e tanto. daltronde, c'è sempre una prima volta grazie veramente per le dritte.[ Auf dieses Posting antworten ]
Antworten
- Enrico Henryx Bianchi (05.07.2008 00:04)
