Newsgroup: it.comp.software.database
Titolo: Re: limiti dei dbms

 anno e mi chiedevo se tra qualche anno posso avere problemi.
Sono pochissimi, fidati :)
Io con MySQL sono arrivato a costruire una tabella con quasi un milione 
e mezzo di records e non ho avuto problemi.
A parte che non credo ci sia fisicamente un problema in termini di 
numero di records, semmai in termini di dimensione dei file che li 
conterranno (con quella tabella sono arrivato a occupare una 80ina di 
MB)...
I DBMS sono costruiti proprio per lavorare su grandi quantità di dati...
Il problema può sorgere nella velocità con cui il motore del db andrà a 
recuperare i dati su cui vorrai lavorare.
Se il software che gestirà i dati è costruito un po' ad minchiam (scusa 
il termine), è logico che sarà lento con tutti quei record.
Se il software invece è stato costruito per lanciare query ben mirate e 
se il db è progettato con gli indici al posto giusto, scordati problemi 
sia in relazione al numero di record massimi che puoi memorizzare che in 
relazione alla velocità del software che gestirà i dati.
Cmq attendo smentite... o_O
-- 
Quando noi ignoranti eravamo di più, tutto era più bello (A. Celentano).
  ___   _   ___ _  _______   _______ ___
|   \ /_\ | _ \ |/ / _ ) \ / /_   _| __|
| |) / _ \|   / ' <| _ \\ V /  | | | _|
|___/_/ \_\_|_\_|\_\___/ |_|   |_| |___|

Mi chiedevo quali sono i limiti, in termini di quantità di record (o meglio
di dimensione di tabelle e/o database) dei principali dbms: MySql, MSSql,
Oracle, PostgreSql ed altri.
Ho infatti la necessità di archiviare tabelle con circa 100.000 record /
anno e mi chiedevo se tra qualche anno posso avere problemi.
Grazie,
Luca

 MB)...
In effetti oltre al numero di record mi preoccupa la dimensione delle
tabelle.
Alcune contengono anche campi di tipo LONGTEXT, e accade spesso che un solo
record occupi alcuni mega.
Ciò significa che potrei trovarmi con tabelle di diversi giga.
Prima dei tempi di accesso mi preoccupa l'integrità dei dati.
Luca

 Le fatture di circa 1000 società dal 2002 ad oggi :)
Il documento scansionato o i dati delle fatture?
Giusto per capire il tipo di dati.
Luca

 sistemi di cui sto parlando :)
E ke č? o_O
Tutti 'sti campi... tutti 'sti record... Ma č Mamma Telecom x caso?
-- 
Quando noi ignoranti eravamo di piů, tutto era piů bello (A. Celentano).



beh su postgresql, ho due tabelle con circa 6 milioni di record ciascuna :)
M.


Faccio esattamente il contrario.
Anzichč salvare l file nel file system, con tutti i problemi di sincronia e
backup che puň dare, li salvo nel database.
Ovviamente sono file legati ai record corrispondenti, ovvero non uso il db
come un filesystem :-)

 sistemi di cui sto parlando :)
ah
tlc cina aveva un db oracle di svariati tera !
e non c'era niente da replicare !
felice_pago
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/



 sistemi di cui sto parlando :)
...
M.

°_°
E che cosa c'è dentro? Giusto x curiosità!
-- 
Quando noi ignoranti eravamo di più, tutto era più bello (A. Celentano).


 Tutti 'sti campi... tutti 'sti record... Ma č Mamma Telecom x caso?
gioco del venerdi ?
no sicuramente sbagliato, la tlc ha si tabella da 100-200 milioni
di record, ma mi auguro con molto meno colonne, altrimenti c'e'
qualcosina di sbagliato, e conoscendo un po di gente di li' . . .


 ha scritto nel messaggio 
news:conlgs$afa$1...@atlantis.cu.mi.it...

Penso di no. Anche in teoria siccome la struttura usata per indicizzare 
tabelle è solitamente il B*-tree, che contiene tanti figli per ogni nodo 
quanti puntatori possono starci in una pagina di memoria. Ora non so le 
pagine quanto grandi siano al giorno d'oggi, cmq ci possono stare parecchi 
figli. Se poi consideri che i figli possono avere altrettanti figli, alla 
fine avrai una profondità dell'albero molto piccola, credo sui 3-4 anche per 
tabelle grandi. Il costo di accesso si calcola solitamente come numero di 
accessi all'albero, che appunto non dovrebbero superare i 3-4. Per 
costringere il B*-tree ad aumentare la profondità dell'albero credo che sia 
necessaria un'esplosione di dati! 

 MySql, MSSql, Oracle, PostgreSql ed altri.
Beh, considera che lavoro giornalmente con un paio di sistemi sviluppati su 
db Oracle che hanno una decina di tabelle contenenti un milione e piu' 
record, un paio di tabelle contenenti 10 milioni di record, ed una tabella 
da 20 milioni di record (il tutto con mi grande gioia nel momento in cui mi 
serve sincronizzarli, visto che i db sono dislocati in due nazioni 
differenti). Per quanto riguarda il contenuto, sono per lo piu' dati di 
tipo char e varchar (le tabelle spaziano dal contenere una trentina di 
campi al contenere piu' di 180 campi)
Henryx
P.S. ovviamente i piu' "fortunati" di voi avranno capito qual e' uno dei 
sistemi di cui sto parlando :)
-- 
Per chi vuole conoscere Firebird, uno dei migliori RDBMS in circolazione:
http://tanit.myftp.org/cgi-bin/firebird/yabb.cgi


I dati...


Preciso, sono dati di fatture (data di emissione, importo, paese) più 
tutta una serie di altri dati, in quanto sono oggetto di assicurazione 
(fido, copertura assicurativa, tasso, premio calcolato, etc)

Scusa, giusto per pignoleria, cosa c'è dentro quei longtext?
Non puoi salvarli su file e memorizzare solo il nome del file nel db?
-- 


 e non c'era niente da replicare !
Il discorso non e' sincronizzarli (alla fine il sistema locale e' un
datawarehouse), piu' che altro ho citato tale progetto per fare un
esempio di db grosse dimensioni. Anzi, a tal proposito: 
- sia il db remoto che quello locale funzionano 24/7;
- il db remoto ha accessi continui sia in lettura che scrittura da varie
  parti dell'europa e da centinaia di pc;
- il db locale e' formato da un solo tablespace di 15Gb (so che e' una
  pazzia, ma non l'ho fatto io);
- il db locale gira su windows 2000, quello remoto non saprei
  (probabilmente su HP-UX, ma e' una mia supposizione);
- la piattaforma locale e' Oracle 8.1.7, quella remota non saprei.
In definitiva, Oracle e' un ottimo db sia in termini di robustezza, sia
in termini di scalabilita' e' un'ottima scelta. Gli unici difetti che vi
vedo sono una eccessiva complessita' nell'amministrazione ed un costo
astronomico. Per quanto riguarda gli altri db, posso dire che sia
PostgreSQL che Firebird gestiscono bene tabelle con un paio di milioni
di record e con gli indici fatti bene (non so dire pero' se la mia sia
una affermazione accettabile, in quanto il test che ho eseguito era con
un solo client) 
Henryx


100.000 recordo sono pochini te lo assicuro, considera
che Oracle ha dei sistemi per velocizzare l'archiviazione di tabelle
che vanno oltre il giga e non ci sono problemi
(anche svariati milioni di record).
SqlServer è più o meno lì ed anche Mysql ti assicuro che gestisce
tranquillamente
tabella da milioni di record.
PostgreSql non lo conosco.
    danilo