altre opinioni ?
altre opinioni ?
up
Io ho testato MySQL esplicitamente fino a 50 milioni di record, con ottime prestazioni!
Il cuore del database sogno gli indici: se dividi la tabelle in più parti spezzi l'indice unico categoria-prodotto e costringi MySQL a fare un join (l'indice non è altro che un join salvato e aggiornato).
Ti conviene quindi:
* mantenere i dati insieme
* studiare bene gli indici: un'unico grosso indice primario occupa meno spazio e dà le stesse identiche prestazioni di più indici (provato su decine di milioni di record!)
* giocare sulla vera forza di MySQL: GLI INTERI CORTI!!!!! Questa è una chicca veramente fenomenale e poco conosciuta. Se io uso un codice di 10 char per un prodotto ho 10 byte per codice; se invece uso un intero posso addirittura appoggiarmi ad uno smallint (fino a 64'000 occorrenze diverse), che a confronto occupa un'inezia, velocizzando anche di 20-30 volte l'accesso; il trucco sta nel lasciare i codici varchar usati dal livello logico come "seconda descrizione" e non come chiave (e così via quando entrano nei documenti etc...)
A dispo per approf
:metallica
<ciao><Enrico/></ciao>
io ho il medesimo problema...
20 utanti contemporanei ed a loro gni click devo incrementare 6 8 contatori...
lo voglio fare con access, possibile?
Secondo me è folle l'idea di gestire un sito che conta mediamente 20 utenti contemporanei con access... poi che sia possibile è tutta un'altra cosa.
Sconsiglio vivamente di registrare eventi numerosi (tipo log) su tabelle Access; non perchè non sia veloce (non è affatto male), quanto perchè essendo non un'anagrafica stabile ma qualcosa del tipo scrivi-cancella (archiviazione dei log dopo un certo numero)l'archivio mdb (che non sia autocompatta) tenderebbe a salire velocemente di dimensione (anche dopo pulitura), costringendo a periodici "pack".
O si usa un database "completo" (MySQL, PSG, Oracle...) oppure, volendo rimanere sui database a file, consiglio SQLite, che assomiglia molto ad Access ed ha istruzioni di pack a livello SQL, lanciabili quindi via web senza necessità di sessioni remote sul server.
<ciao><Enrico/></ciao>
Originariamente inviato da Enrico Modanese
Io ho testato MySQL esplicitamente fino a 50 milioni di record, con ottime prestazioni!
Il cuore del database sogno gli indici: se dividi la tabelle in più parti spezzi l'indice unico categoria-prodotto e costringi MySQL a fare un join (l'indice non è altro che un join salvato e aggiornato).
Ti conviene quindi:
* mantenere i dati insieme
* studiare bene gli indici: un'unico grosso indice primario occupa meno spazio e dà le stesse identiche prestazioni di più indici (provato su decine di milioni di record!)
* giocare sulla vera forza di MySQL: GLI INTERI CORTI!!!!! Questa è una chicca veramente fenomenale e poco conosciuta. Se io uso un codice di 10 char per un prodotto ho 10 byte per codice; se invece uso un intero posso addirittura appoggiarmi ad uno smallint (fino a 64'000 occorrenze diverse), che a confronto occupa un'inezia, velocizzando anche di 20-30 volte l'accesso; il trucco sta nel lasciare i codici varchar usati dal livello logico come "seconda descrizione" e non come chiave (e così via quando entrano nei documenti etc...)
A dispo per approf
:metallica
Non ho capito bene l'ultima parte. Come faccio a fare una ricerca di tipo testuale su un campo numerico ?
Come me la sbrigo con le ricerche fulltext?
Ho capito quello che dici, ma questo andrà bene solo per una strutturazione del progetto atta ad una visualizzazzione del prodotto per categorie. Come faccio invece per la ricerca libera all'interno del db?
Io provo a dare una risposta teorica, non conoscendo bene il tuo caso. Nella progettazione del database e delle numerosità, solitamente i volumi maggiori si accentrano nelle relazioni, mentre le entità rimangono piccole. In parole povere: ho milioni di ordini / acquisti, ma su alcune decine di migliaia di prodotti. In questo caso due campi interi ridotti (ad esempio cliente - prodotto) possono generare milioni di combinazioni.
Se invece, come nel tuo caso, ogni record ha un suo contenuto testuale, diventando una vera e proria entità, il problema si complica, perchè fare un full text su 5 milioni di record è un mezzo suicidio. Posso dirti come fanno quelli che gestiscono grossi motori di ricerca: classifichi i prodotti in base a famiglie predefinite (qui si può decidere se creare fino a n campi oppure un solo campo e numero arbitrario di righe di classificazione per ogni prodotto) e poi effettui la ricerca sulle tabelline di controllo delle famiglie, per poi affinarla sul subset di prodotti così estratto. In alternativa puoi utilizzare le indicizzazioni fulltext di MySQL, ma dovresti avere un demone che non fa altro che continuare ad aggiornare il tutto (sistemisticamente abbastanza pesante).
<ciao><Enrico/></ciao>
Più o meno ho capito la logica che a quanto sembra dovrebbe essere difficile da applicare. Posso trovare documentazione in merito all'ultima proposta che mi hai fatto?
ti ringrazio
finalmente qualcuno che conosce bene questo tipo di settore
Permessi di invio
Rispondi quotando