nntp2http.com
Posting
Suche
Optionen
Hilfe & Kontakt

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