Come selezionare un database SQL?

Question

Viviamo nell'epoca d'oro dei database, con numerosi database commerciali e gratuiti di alta qualità.Questo è fantastico, ma lo svantaggio è che non esiste una scelta semplice e ovvia per chi ha bisogno di un database per il suo prossimo progetto.

• Quali sono i vincoli/criteri che usi per selezionare un database?
• In che misura i vari database che hai utilizzato soddisfano tali vincoli/criteri?
• Quali caratteristiche particolari hanno i database?
• Quali database ti senti a tuo agio nel consigliare ad altri?

eccetera...

Answer 1

Penserei prima a quali sono i requisiti di sistema per l'accesso ai dati, la sicurezza dei dati, la scalabilità, le prestazioni, gli scenari disconnessi, la trasformazione dei dati, il dimensionamento dei dati.

D'altra parte, considera anche l'esperienza e il background di sviluppatori, operatori, amministratori di piattaforma.

Dovresti anche pensare a quali vincoli hai riguardo ai linguaggi di programmazione, ai sistemi operativi, all'impronta di memoria, alla larghezza di banda della rete, all'hardware.

Ultimo ma non meno importante, bisogna pensare a questioni aziendali come il budget per le licenze, il supporto, il funzionamento.

Dopo tutte queste considerazioni dovresti ritrovarti con solo un paio di opzioni e la selezione dovrebbe essere più semplice.

In altre parole, seleziona la tecnologia che meglio si adatta ai vincoli e alle esigenze della tua organizzazione e del tuo progetto.

Sicuramente penso che tu abbia ragione nel dire che non è una scelta ovvia dato l'ampio numero di alternative, ma questo è l'unico modo in cui penso che tu possa restringerle a quelle realmente fattibili per il tuo progetto.

Answer 2

I miei criteri di selezione (principalmente incentrati sulla programmazione):

• Manutenzione:Come vengono installati gli aggiornamenti/hotfix?
• Controllo delle transazioni:Come viene implementato
• Sono supportate le procedure memorizzate?
• È possibile utilizzare la gestione delle eccezioni nelle procedure memorizzate?
• Costi
• Come vantaggio:È possibile utilizzare la ricorsione sulle procedure memorizzate?(Per esempio.in SQL Server 2000 la ricorsione si interrompe dopo 32 passaggi IIRC)

Answer 3

Per la maggior parte delle persone in un ambiente aziendale la scelta si riduce a "quello che abbiamo".

Dato che sembri essere abbastanza fortunato da avere una scelta, farò una rapida panoramica delle domande e magari ne porrò qualcuna alla fine.

Il criterio più importante potrebbe essere il costo.Vuoi/sei disposto a pagare per la tua piattaforma DBMS?In caso contrario, probabilmente sono usciti Oracle, MS SQL Server, Sybase e altri, anche se se non stai creando un'app commerciale potrebbe esserci un po' di margine di manovra.Inoltre, piattaforma: puoi eseguire il software sul tuo hardware?

Altre dimensioni da considerare potrebbero includere il numero previsto di connessioni simultanee, transazioni transazionali o per lo più letture, dimensioni, disponibilità e immagino molte altre.

Le "caratteristiche speciali" sono, nel complesso, da evitare: nella mia cinica visione del mondo hanno lo scopo di bloccarti in una piattaforma.Quindi qualcosa come PL/SQL di Oracle è una funzionalità che, sebbene potente (e probabilmente significa la necessità di potenza aggiuntiva della CPU a costi di licenza maggiori) non è portatile.Se ti aspetti volumi estremamente elevati, suppongo che il partizionamento possa essere utile.

Ho lavorato con Oracle, MS SQL Server, MySQL, PostreSQL, SQLite e Sybase a cui riesco a pensare.Consiglierei volentieri tutti tranne Sybase, riguardo al quale ho qualche preoccupazione in questi giorni (potrei facilmente sbagliarmi, ma personalmente penso che i soldi potrebbero essere spesi meglio altrove) ma non tutti per le stesse applicazioni.

Idealmente, mi piace avere la calda sensazione che non abbia molta importanza quale piattaforma DB sto utilizzando perché posso portarla facilmente.Con un buon livello di astrazione tra dati e logica di business, dovrei essere in grado di sviluppare localmente, ad esempio, contro l'eccellente SQLite e implementarlo senza problemi, ad esempio, su Postgres.Con qualcosa come ActiveRecord di Rails abbinato a un po' di consapevolezza di cose come le differenze nelle parole riservate, questo è quasi completamente gratuito.

Answer 4

Sicuramente il fattore più interessante è l'esperienza tua o del tuo team... o il pool di risorse che probabilmente assumerai in futuro.Tenderei ad andare avanti per la maggior parte del tempo, utilizzando MySQL in un team LAMP e SQL Server in un team MS, poiché entrambi questi prodotti sono in grado di fare tutto il necessario anche in un ambiente ad alto carico.

I vantaggi di qualsiasi altro database saranno marginali rispetto alla difficoltà di imparare a usarlo bene.L’unica eccezione a questo, a mio parere, sarebbe in un ambiente ad alta domanda in cui:

UN.la scelta ovvia è stata tentata e sta fallendo

B.i benefici del ridimensionamento moltiplicano il beneficio marginale a tal punto che varrà il costo dell’utilizzo di qualcosa di inaspettato.

Darei per scontato la necessità di assumere almeno due e preferibilmente tre eccellenti DBA con familiarità a lungo termine con il nuovo database.

E per prima cosa proverei ad assumerli per la tecnologia che stava fallendo, perché è più probabile che sia il modo in cui viene utilizzata piuttosto che la tecnologia stessa a causare il problema.

Answer 5

Le risposte esistenti sono fantastiche.Vale la pena ricordare che Oracle ora dispone di una versione XE del suo database 10g disponibile gratuitamente e fornita con Application Express, un ottimo ambiente di sviluppo basato sul web.

È limitato, 4 GB HD, 1 GB Ram e utilizza solo una CPU.Questo è sufficiente per eseguire sistemi più piccoli e può essere aggiornato facilmente in un secondo momento, se necessario.Oracle può essere uno dei più difficili da imparare, ma è anche uno dei migliori da avere nel tuo CV :-)

Penso che SQLServer di Microsoft abbia anche un database di tipo "starter".Non sottovalutare i prodotti commerciali: se hai intenzione di scommettere con la tua azienda su una tecnologia di database, preferirei utilizzare personalmente un prodotto Oracle o Microsoft.Questo non vuol dire che ci sia qualcosa di sbagliato nell'Open Source.

Prendetevi un po' di tempo per valutarli :-)

Answer 6

• Linux, ospitato sul Web - MySQL (forse PostreSQL)
• PMI tradizionale: MS SQL
• Big Iron (bancario, ecc.) - Oracle

Pensare a qualcosa di diverso da questi tre è masturbazione: qualsiasi altro database diventa una discussione su prodotti di nicchia per risolvere problemi particolari che probabilmente non hai ancora incontrato.Se scegli qualcosa di diverso dai tre sopra indicati, dovrai:

1. Lotta per trovare persone che lavorino al progetto o per mantenere attivo il database
2. Lotta per motivare la tua decisione senza una discussione accademica
3. Qualcuno maledirà te, i tuoi antenati e il tuo lignaggio tra qualche anno - e sostituirà comunque la tua scelta.

I database di nicchia non sono il luogo in cui vengono fatti passi da gigante in termini di architettura: si tratta di tecnologie come middleware, messaggistica, servizi cloud ecc. dove puoi permetterti (e dovresti) esasperarti per trovare buoni prodotti.