Newsgroup: it.lavoro.informatica
Titolo: DBMS e performance

Ciao a tutti,
qualcuno di voi si è mai trovato a dover scegliere su quale DBMS 
implementare un progetto? Io sono indeciso tra SQL Server, PostgreSQL e 
Oracle. A tal riguardo vi chiedo se esistano delle analisi comparative 
sulle performance in modo da potermi orientare a seconda del mio problema.
Grazie in anticipo,
Giulio
-- 

 del mio problema.
Dipende da quello che devi fare, dal tipo di transazioni, numero di 
utenti concorrenti, dimensione dei dati, e dal budget del progetto.
Oracle costa più di SQL Server ma ti assicura prestazioni migliori e 
gestione più avanzata di transazioni, utenti, grant, ecc..
PostgreSQL non lo conosco anche se so che è free e ha una buona qualità.
Ciao,
Domenico


Be', dipende appunto da quello che deve fare, può essere che per i suoi
obiettivi i due prodotti si equivalgano prestazionalmente, con un po' di
vantaggio lato MS per i costi.
Ciao, Alessandro
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sulle performance in modo da potermi orientare a seconda del mio problema.
le performance in genere sono l'ultimo degli aspetti da considerare;
in genere il primo è, tristemente, il costo, il secondo è il know-how
a disposizione, il terzo sono le feature.
Ovvio poi che ci possono essere controesempi, ma considera che
postgreSQL è gratis, SQL server costa da 3000 a 8000 euro mi pare (ma
non sono aggiornato), Oracle può costare da zero a 200000 euro a
seconda della versione che scegli. Questo già a volte può determinare
la decisione ;^)
Il discorso sul know how è relativo sia a chi deve sviluppare il
progetto sia a chi lo acquisisce (il cliente, insomma). Ogni ambiente
ha le sue forze e limitazioni e conoscerlo bene rende molto più breve
il tempo di sviluppo e molto meno faticosa la manutenzione.
Infine vengono le feature; per dire, se hai bisogno di realizzare un
DB distribuito o replicato, almeno fino a qualche tempo fa postgreSQL
non era la soluzione migliore perchè non offriva la replicazione
nativa ma solo tramite un add-in (può pure darsi che nel frattempo ce
l'abbiano messa, era per fare un esempio). Se invece hai bisogno di
fare una costumizzazione al codice PostgreSQL è l'unica soluzione
percorribile, visto che dubito che tu riesca a mettere le mani sul
codice di Oracle o SQL Server ;^)
bye!

 Giulio
Prego, però era meglio se dicevi cosa devi fare e con che
risorse :-)
Lucazeo

 implementare un progetto?
In passato svariate volte. Adesso non più.
Se si tratta di un progetto commissionato con specifico DBMS fra i
requisiti ovviamente implemento su quel DBMS, ma in quel caso non devo
fare nessuna scelta. Se la scelta dipende da me semplicemente non la
faccio :-) Uso tecniche di sviluppo DBMS-indipendenti e lascio la
scelta ad altri. Le performances del DB non sono fondamentalmente un
problema di chi realizza il progetto software.

 problema di chi realizza il progetto software.
Posso capire che i costi non ti riguardino,
ma tecniche di sviluppo DBMS-indipendenti significa che non usi stored
procedure, viste, tipizzazione, partizionamento di tabelle e via
dicendo?
Ci sono molte cose che influiscono sulle performance e progetti
multi database hanno vantaggi e svantaggi.
Il vantaggio è che lo puoi vendere a chi già ha grossi sistemi in casa
senza troppo sbattimento. (vantaggio commerciale)
Lo svantaggio è che, o scrivi procedure e viste per n database
o le performances su sistemi grandi decadono. O entrambe
le cose. (vedi sap ed altri).
Compagnie grandi, come le telefoniche, o industrie, spesso sviluppano
i loro sistemi per un tipo di database, riuscendo così a ottimizzare
le prestazioni. Indispensabile in questo caso.
Legarsi ad un motore di database può sembrare restrittivo, perchè si
dipende da un produttore, un prodotto e la sua evoluzione, ma
spesso non si può farne a meno.
Lucazeo

Giulio Petrucci wrote:
: Ciao a tutti,

Quanti dati devi gestire?
Hai bisogno di continuità di servizio?

 Hai bisogno di continuità di servizio?
In fase di sviluppo/prototipazione non è un requisito "fondamentale", 
mentre lo sarà in produzione.
Ciao e grazie,
Giulio
--
OnAir: Judas Priest - "The Sentinel"

 le prestazioni. Indispensabile in questo caso.
Ma in quel caso non sei tu a fare la scelta, il DBMS è un requisito.
E' ovvio se se sviluppi un progetto per un cliente che ti impone un
certo DBMS sviluppi su quel DBMS, ma a quel punto non ha nemmeno senso
porsi la domanda sulla scelta.

Giulio Petrucci wrote:
: GdG ha scritto:
:: Quanti dati devi gestire?
:
: Tecnicamente, per ora (i.e.:specifiche incomplete) la tabella critica
: è una che dovrebbe avere circa 200mln di righe.
:
:: Hai bisogno di continuità di servizio?
:
: In fase di sviluppo/prototipazione non è un requisito "fondamentale",
: mentre lo sarà in produzione.
:
Oracle o SQLServer. Non è che hai molta scelta.
Forse come costi SQLServer 2005 in configurazione Mirroring usando il Client 
SQL Nativo.
Se l'applicazione nasce .NET è la soluzione migliore.

 una che dovrebbe avere circa 200mln di righe.
Ok, ti posso dire cosa sto facendo io.
Sto finendo un DB da 300 milioni di record, con 50 tabelle,
partizionate su 3077 filegroup.
(Si, si... 50 stati USA e 3077 contee)
Con ricerche per nome, data di nascita, tabella "Alias" e un po' di
"Fuzzy Logic" sul nome (Robert, Bob, Bobby, Rob...)
Il tutto in SQL Server 2005.
Prestazioni di buon livello, anche se non e' richiesta una risposta
istantanea.
P