Come scegliere DB e / o DBMS per la propria applicazione? [chiuso]

Se l'applicazione è locale (non supporta l'accesso remoto) è possibile utilizzare un motore DB incorporato.

Ti dà la facile installazione e indipendenza dagli altri programmi installati. Quindi è necessario scegliere la libreria appropriata. Cosa cercare quando si sceglie?

1. Come ho detto, la libreria dovrebbe essere incorporata. Ti consente di creare il singolo file eseguibile senza configurazioni difficili.

2. La libreria dovrebbe supportare C / C ++ per l'integrazione con il codice esistente.

3. La libreria dovrebbe essere ben nota e ampiamente utilizzata. Assicura che gli errori più terribili siano già stati scoperti e risolti.

4. È facoltativo, ma sarebbe bello se potessi scrivere query SQL.

5. È facoltativo, ma ... open-source!

Bene, qual è la scelta?

Propongo di prestare attenzione a SQLite e Berkeley DB . Entrambi sono incorporati, entrambi sono open-source, entrambi supportano C / C ++ (anche Java, Python, ecc.)

SQLite è un motore di DB relazionale, dal momento che Berkeley DB non lo è. La mia opinione, SQLite è abbastanza facile da imparare, ma potrei sbagliarmi.

Prova entrambi. Usa quello che funzionerà prima.

Prima di tutto. Non preoccupartene molto. Quando separi bene le tue preoccupazioni, recuperi i dati, dall'elaborazione e dalla visualizzazione, avrai sempre la possibilità di passare a un sistema "migliore".

Le dimensioni di circa 10.000 voci non sono nulla di cui lamentarsi un database, anche milioni di set non sono un grosso problema. Il tuo database dovrà crescere man mano che la tua applicazione / sistema crescerà. Pensa ai più comuni casi di utilizzo e quali dati vengono presentati insieme e quali dati vengono utilizzati insieme. Questo dovrebbe portarti a scegliere se utilizzare un database di colonne, un database di documenti, un database di grafici o semplicemente un database relazionale.

Non pensare troppo a problemi di prestazioni o problemi teorici che potrebbero verificarsi, definire ciò che è importante e selezionare un sistema, che puoi ottenere il massimo supporto. Ricordati di disaccoppiare i tuoi dati (modello) dalla tua applicazione (logica) e presentazione (vista), quindi puoi sempre fare un'ipotesi meglio informata la prossima volta. Quando rendi la tua applicazione open source un design disaccoppiato incoraggerà gli altri a fornire un'implementazione del database quando richiesto, che potrebbe essere più adatto ai tuoi (o ai tuoi) bisogni.

C'è molta conoscenza in giro - Pensa prima abbastanza bene. Sii pragmatico.

Controlla il link che ho condiviso nella sezione dei commenti. Questa è una buona panoramica su pro e contro sul tipo di database che potrebbe essere necessario.

Prima di tutto, dove vedi la gerarchia, un esperto di database vede le relazioni. Prenditi del tempo per capire il modello di database relazionale e crea un modello semplice che si adatti ai tuoi dati. Questo modello classico è provato e testato, basato su basi matematiche ed è la base per praticamente ogni grande sistema là fuori. Non farti ingannare dalle persone che sostengono che un database grafico o database NoSQL risolverà i tuoi problemi immediati. Molto spesso sono ignari della corretta progettazione del database e della manutenzione a medio-lungo termine. I database di grafi e i database NoSQL brillano in nicchie molto specifiche dell'ingegneria del software, ma la scelta di usarli dovrebbe generalmente essere fatta dopo che le soluzioni convenzionali si rivelano insufficienti.

Le prestazioni dovrebbero essere chiaramente prese in considerazione in quanto un milione di record potrebbe già rappresentare un problema quando si affrontano determinati scenari di richiesta-risposta. Ad esempio, potresti voler fornire una risposta entro 200 millisecondi, il che probabilmente implicherebbe l'uso di indici.

Per scegliere un DBMS, dovresti iniziare con PostgreSQL. Ha un ottimo track record, viene fornito con un performant query optimizer, è ragionevolmente standard SQL e viene utilizzato in molte (più grandi) impostazioni di produzione. Ho personalmente progettato e implementato le impostazioni di PostgreSQL contenenti decine di miliardi di record, centinaia di tabelle e probabilmente migliaia di indici, guidando le applicazioni SaaS con caratteristiche prestazionali di tutto rispetto.