Newsgroup: it.comp.programmare
Titolo: Benchmark linguaggi e database

Tempo fa avevo visto un sito con dei benchmark di vari linguaggi di 
programmazione, in particolare per ogni linguaggio vi erano indicati il 
tempo e la memoria occupata per determinare operazioni, come lavorare con 
array e matrici, e via dicendo...io l'ho perso, mi potreste aiutare?
Esiste, che voi sappiate, un sito con benchmark simili per database (nel 
senso, non mi interessa sapere se un db ha l'integrità referenziale ed 
un'altro no, ma a parita di schema il piu' efficiente ad esempio nelle query 
di insert con unc erto numero di campi, o cosi via...)
Grazie mille!!!!
-- 
"Avro' qualche problema con lei, signor Bond?"
"No, lei non e' il mio tipo"
"Brillante?"
"No, single" 

 Esiste, che voi sappiate, un sito con benchmark simili per database
Su questo non so aiutarti.
Saluti,
The Librarian

 di insert con unc erto numero di campi, o cosi via...)
Cioè ti interessa sapere quale sia il db più veloce senza curarti di
come tratta i tuoi dati?
Tieni presente che stai confrontando pere con mele.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.


Perfetto, era proprio lui, grazie mille!


Mi sa che mi sono espresso male... o forse no....
Per ora, tutti i benchmark che ho trovato sono solo sulle differenze
"formali" di un db o del tipo di engine,  tipo se il lock viene
eseguito sull'intera tabella o ce c'e' o meno la possibilita' di usare
l'integrita' referenziale...io vorrei sapere, specificatamente nel
caso di query di insert, quale e' il piu' performante a parita' di
dato da inserire.....l'applicazione che devo sviluppare richiede di
eseguire qualche milione di insert ad ogni funzionamento, e se riesco
a risparmiare anche un niente in termini di tempo di inserimento su
ogni insert.....

 ogni insert.....
Be', allora scaricati PostgreSQL, MySQL, Firebird, MSDE (SQL Server),
Oracle (è gratuito per lo sviluppatore) e fai un milione di insert. Fai
una media dei tempi e ragiona su quella. Questo test è insignificante per
il 99% delle applicazioni, ma magari a te è utile.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Mi sa che mi sono espresso male... o forse no....
Allora: se a te non frega nulla dell'integrità referenziale,
probabilmente ci sono metodi più veloci di un db.
Un db ha delle garanzie, garanzie che 'costano'. Un db supporta accessi
concorrenti, integrità referenziale, etc etc etc. Tutto questo ha un
costo.
Se tu devi prendere roba e buttarla su disco e 'fanculo', beh, allora
c'è caso che *nessun* db sia una scelta più opportuna. A patto di avere
qualcuno che sa scrivere come si deve routine di IO.


 il 99% delle applicazioni, ma magari a te è utile.
Secondo te invece quali sono i test di velocita' significativi per la 
maggior parte delle applicazioni?
Penso che leggere i test fatti da un altro sia piu' semplice che farli 
in proprio.
D'altra parte, anche per scoprire quale automobile e' piu' veloce basta 
provarle tutte, pero', chissa' perche', ci sono riviste che pubblicano i 
risultati dei propri test di velocita'.
E dire per il software la velocita' e' molto piu' importante che per le 
automobili. Infatti, le automobili meno potenti hanno comunque velocita' 
decenti e le automobili piu' potenti non potrebbero superare i limiti di 
legge, e anche volendo, spesso non possono andare molto veloci a causa 
della strada o del traffico, mentre per il software, si puo' avere che 
un programma e' decine di volte piu' veloce di un altro programma 
equivalente.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

maggior parte delle applicazioni?
La "velocità" non è il valore principale da tener presente quando si
valuta un "programma" rispetto a un altro. E tanto più quando il
"programma" è un DBMS. Se vuoi fare un "test di velocità", come ho già
detto, lo fai e ti accontenti dei risultati. Quando si valuta un DBMS,
però, bisogna considerare mille aspetti diversi, a seconda delle
proprie esigenze, proprio perché un DBMS è molto più complesso che
un'automobile.

Andrea Laforgia ha scritto:

Mi pare che l'OP aveva gia' trovato informazioni esaurienti a proposito 
degli altri aspetti, e gli mancavano solamente i dati relativi alle 
prestazioni.
Non sarei tanto sicuro che un DBMS sia "molto più complesso " di 
un'automobile.
Comunque, tornando alla metafora automobilistica, non mi pare corretto, 
  a chi chiede se ci sono dati di test imparziali sui consumi delle 
automobili rispondere che non si possono confrontare le auto a 2 posti 
con quelle a 4 o piu' posti e che gli unici fattori da tenere in 
considerazione quando si sceglie un'automobile sono il prezzo, il numero 
di posti, l'affidabilita', la sicurezza, e il comfort. A qualcuno 
possono interessare anche i consumi, soprattutto se ci sono vetture che 
consumano 4 volte altre vetture, o se fa fatica a racimolare i soldi per 
il carburante.


un'automobile.
Lo è, invece, e comunque confronti del genere non portano da nessuna
parte. Tronco tutto il resto di quel che scrivi perché lo reputo
assolutamente sterile ai fini della discussione.
L'OP necessita di un DBMS. Se vuol fare un test di velocità, lo faccia
pure, ma non è sui test di velocità che si basa, normalmente,
l'adozione di un DBMS. Almeno, non solo su quelli. Ci sono miliardi di
aspetti da considerare, anche in virtù delle proprie esigenze.
Questo è quello che io ho detto, se vuoi parlare di automobili non ti
seguirò.

 prestazioni.
E io mi permetto di rispondere nuovamente, se di tutte le
caratteristiche di un dbms non gli interessa nulla di integrità
referenziale e compagnia (roba che *comunque* paga), probabilmente ci
sono soluzioni più interessanti.
Droppando accesso concorrente (e quindi parecchi lock e unlock) e
vincoli, IMHO si può usare qualcosa di più veloce.


 c'è caso che *nessun* db sia una scelta più opportuna.
Si', o nessun db, o mysql. Il risultato non cambia di molto.

 Si', o nessun db, o mysql. Il risultato non cambia di molto.
appunto. :)



[CUT]
Mi ero dimenticato di questa discussione... ;P
Allora, il punto è che devo estrapolare delle stringhe e fare delle 
operazioni di verifica sui dati.
I dati non devono essere mantenuti memorizzati, devono solo essere validati 
in un qualche modo.
Ora, questa validazione puo' essere implementata con poche righe di codice 
appoggiandosi ad un db, o si possono realizzare appoggiandosi a strutture di 
dati come hash table, array, etc, ma con molte righe di codice in piu'.
Poiche' e' un fattore fondamentale il tempo di esecuzione, devo valutare 
quale delle due strade sia la piu' efficiente, intendendo con efficiente il 
giusto compromesso tra prestazioni, manutenibilita' e bug (meno righe = meno 
problemi, non solo nella programmazione).
Il risultato è che sicuramente il db piu' veloce ad effettuare query di 
insert o select è migliore, per me.
Lo scaricare n db, e fare m test sarebbe sicuramente un modo per fare i 
benchmark (anzi, e'IL modo) ma non ho molto tempo da dedicare a questa cosa. 
Da qui il post...
Voi, dovendo scegliere una strada 'alla cieca', quale prendereste? Perche'? 
Io ho iniziato a sviluppare appoggiandomi a hash map e similari, ma il 
codice diventa un poco piu' complesso e (forse) inizio a pentirmene un 
pochino (in pratica devo implementare una sorta di select sui dati, 
concatenare tra loro i cambi per associarli ad una chiave hash...) 

Prova la BerkeleyDB:
http://en.wikipedia.org/wiki/Berkeley_DB