3 veloci! - Napolux

la domanda era avere 5 colonne in una tabella o solo 2 - Nicola Greco

Beh, se hai questi dubbi dovresti chiederti se lo schema del DB è ok oppure ha bisogno di qualche sistematina :P - Napolux

3 sveltine ;) - Irrisolta from FreshFeed

In altri campi sono per una fatta come si deve. Anche se nei db è difficile che dopo il server si fumi una sigaretta. - Napolux

io sceglierei la soluzione che, all'aumentare dei dati, scala meglio - Matteo

non esiste una soluzione migliore, solo quella ideale nel caso :) - Alessiobblà

ma no Piplos, dipende sempre dal caso, una query grossa ti porta un carico maggiore, magari tre piccole se spezzate in modo razionale lasciano il tempo al server di lavorare ad ogni task in modo efficace, magari anche mettendoci meno. Dipende da che query è, se è una query immensa magari è meglio spezzare, se è una query non gigante allora la fai pesante ma non troppo e la tieni unica. - Alessiobblà

bisogna valutare caso per caso, ovviamente, tenendo ben presente inoltre la necessità di svolgere le eventuali tre (n) query piccole in transazione, con il relativo overhead - alb.ert.one

cambiamo la domanda, meglio 3 query piccole, una join o una pesante? - Nicola Greco

non ho il db con abbastanza dati, perderei più tempo credo. va beh dai lo faccio.. - Nicola Greco

Appunto, fatti un benchmark nicola. Anche se artigianale (dati farlocchi e query ripetute 100.000 volte) può darti un'idea precisa. http://ste95.wordpress.com/2009... così puoi giocare con tutti i casi (transazioni, 3 query piccole VS una grossa, join, ecc...) - Napolux

si ma testo direttamente inviando sql al database. comunque la differenza è avere 3 tabelle con 2 colonne o avere 1 tabella con 5 colonne. A questo punto la differenza è minima, meglio avere tutto in un'unica tabella. - Nicola Greco

ma il numero di record è lo stesso in tutte e tre le tabelle?? - peppe, in cerca di nick.

non ti ho capito - Nicola Greco

le tre tabelle hanno lo stesso numero di righe? - peppe, in cerca di nick.

se la query deve essere lanciata una sola volta e basta può anche essere unica e grossa, soprattutto se è in sola lettura, se invece parte ad esempio, ad ogni visita, ed oltre a leggere scrive anche dati nei db è meglio usare a) indici b) cache c) 3 query veloci le slow queries in un db è sempre meglio evitarle. - M0rF3uS #pucciaffa_ftw ✠

ti faccio un esempio: TAB1 (id, nome, cognome) TAB2 (id, città, stato) TAB3 (id, var1, var2) alternativa sarebbe TABUNICA (id, nome, cognome, città, stato, var1, var2) pero poi quando vado a prendere tutti quelli che hanno città = roma, è più pesante. (la tabella non è proprio cosi ma questa rende l'idea) - Nicola Greco

non è vero perchè con 3 tabelle devi fare cmq le join tra le varie tabelle perchè devi sapere i record che hanno "roma" a quale "nome e cognome" corrispondono, quindi cosi come hai posto l'esempio, una unica tabella è equivalente a 3 tabelle, anzi con l'unica tabella ti eviti le join - M0rF3uS #pucciaffa_ftw ✠

tabella people: (id bigint, nome varchar, cognome varchar, città int) tabella città (id int, nome città varchar, nome stato varchar) - peppe, in cerca di nick.

è assurdo avere 15k volte scritto "roma" nel database... non considererei mai di usare una tabella unica in questo caso. - peppe, in cerca di nick.

ma tanto se devi fare le join il lavoro è equivalente - M0rF3uS #pucciaffa_ftw ✠

no aspetta, a me la tabella unica non serve mai, a me serve fare tante query su singole frazioni, ad esempio quante persone sono di roma, o quante hanno il nome carlo - Nicola Greco

ah ok allora cosi ha senso avere più tabelle.... - M0rF3uS #pucciaffa_ftw ✠

Nicola, potresti anche tenere le N tabelle e creare qualche vista con i dati "aggregati" come servono a te. In questo modo la creazione delle viste (1 sola volta) potrebbe essere lenta, l'update delle singole tabelle (poche volte rispetto alle interrogazioni, credo) ci metterebbe un po' di più, ma le query in lettura dovrebbero guadagnarci rispetto a fare join ogni volta. - Matteo

non ti seguo, il problema è se usare where citta=id o where citta=string? - peppe, in cerca di nick.

citta = string - Nicola Greco

citta=string nella tabella cities, citta=int nella tabella people, è la mia idea. - peppe, in cerca di nick.

poi c'è la tabella TAB3 (id, count_1, count_2 ) che devo aggiornare ogni volta che qualcuno visita una determinata pagina con un +1, quindi meglio tenere da parte questa tabella o farne una unica? - Nicola Greco

tab3(id, idpagina, idutente, count) direi. e la immagino come una tabella che ha più update che select. - peppe, in cerca di nick.

quindi mi dici di dividere la tabella dei count da quella grande? - Nicola Greco

ovvio, è un'applicazione a parte in pratica. non appesantire la tabella che deve fare il lavoro vero con le sue statistiche di utilizzo. - peppe, in cerca di nick.

ok quindi farei 2 tabelle, una per le cose statiche e una per le cose dinamiche. - Nicola Greco

decisamente si :D - Alessiobblà

si anche io farei come da ultima soluzione, anche se sono dell'idea che ogni caso va gestito con una soluzione mirata. La valutazione va fatta sulla base della frequenza di accesso, del numero di record e inoltre anche molto dalla modalità di accesso in cui è strutturato l'applicativo (se si utilizzano pattern, se si utilizza la cache e via dicendo). - Fabio Lalli

Usa Doctrine, imposta le giuste relazioni tra le tabelle e lui farà il resto - Leonardo Pellicciotta

E si, io uso Doctrine con Symfony e ha veramente il suo perchè :) Trovo sia uno dei migliori orm... - Fabio Lalli