Quando è il momento di cambiare i backend del database?

https://stackoverflow.com/questions/74261

09-06-2019
|

Domanda

Esiste una regola pratica generale da seguire quando si archiviano i dati delle applicazioni Web per sapere quale backend del database utilizzare?Il numero di riscontri giornalieri, il numero di righe di dati o altri parametri che dovrei considerare nella scelta?

La mia idea iniziale è che l'ordine sarebbe simile al seguente (ma non necessariamente, motivo per cui sto ponendo la domanda).

File piatti
BDB
SQLite
MySQL
PostgreSQL
server SQL
Oracolo

Soluzione

Non è così facile.L'unica regola generale è che dovresti cercare un'altra soluzione quando quella attuale non riesce più a tenere il passo.Ciò potrebbe includere l’utilizzo di software, hardware o architettura diversi (non necessariamente in un ordine fisso a livello globale).

Probabilmente otterrai molti più vantaggi dalla memorizzazione nella cache dei dati utilizzando qualcosa di simile memcached piuttosto che passare a un altro backend di archiviazione casuale.

Altri suggerimenti

Se pensi che avrai mai bisogno di uno dei pesi massimi (SqlServer, Oracle), dovresti iniziare con uno di questi all'inizio.Le migrazioni dei dati sono estremamente difficili.Nel lungo periodo ti costerà meno iniziare semplicemente dall’alto e rimanerci.

Penso che tu sia eccessivamente specifico nelle tue classifiche.Puoi praticamente iniziare con file flat e simili per set di dati molto piccoli, passare a qualcosa come DBM per quelli leggermente più grandi che non richiedono una sintassi simile a SQL e successivamente passare a una sorta di database SQL.

Ma chi vuole fare tutta quella riscrittura?Se l'applicazione trarrà vantaggio dall'accesso a join, procedure memorizzate, trigger, convalida di chiavi esterne e simili, è sufficiente utilizzare un database SQL indipendentemente dalla dimensione del set di dati.

Quale dovrebbe dipendere più dalle installazioni esistenti del cliente e dalle competenze DBA disponibili che dalla quantità di dati in tuo possesso.

In altre parole, la dimensione del database non è l’unica considerazione, e forse nemmeno la più importante.

Non esiste una risposta generale a questa domanda, ma QUASI sempre, l'utilizzo di file flat non è una buona idea.Devi analizzarli (suppongo) e non si adattano bene.Iniziare con un database adeguato, come Oracle o SQL Server (o MySQL, Postgres se stai cercando opzioni gratuite) è una buona idea.Con un costo minimo, ti risparmierai un sacco di fatica e mal di testa in seguito.Ti consentono inoltre di strutturare i tuoi dati in modo non stupido, lasciandoti libero di pensare a COSA farai con i dati piuttosto che a COME inserirli/uscirli.

Dipende davvero dai tuoi dati e da come intendi utilizzarli.In una delle mie posizioni precedenti, abbiamo utilizzato Postgres a causa delle estensioni native di geolocalizzazione e fuso orario che esistevano perché ci consentiva di gestire i nostri dati utilizzando tipi di dati poligonali.Per noi era necessario farlo e volevamo anche utilizzare procedure memorizzate, visualizzazioni e simili.

Ora, un altro posto in cui ho lavorato utilizzava MySQL semplicemente perché i dati erano normalizzati, dati standard riga per riga.

SQL Server, per molto tempo, ha avuto un limite di database di 4 GB (vedi SQL Server 2000), ma nonostante tale limitazione rimane una piattaforma molto stabile per applicazioni di piccole e medie dimensioni per le quali i vecchi dati vengono eliminati.

Ora, lavorando con Oracle e SQL Server 05/08, tutto quello che posso dirti è che se vuoi la crema del raccolto in termini di stabilità, scalabilità e flessibilità, allora questi due sono la soluzione migliore.Per le applicazioni aziendali, le consiglio vivamente (semplicemente perché è ciò che usiamo dove lavoro adesso).

Altre cose da considerare:

Integrazione linguistica (archiviazione di sessioni ASP.NET, gestione dei ruoli, ecc.)
Tipi di query (Seleziona, Aggiorna, Elimina) [sebbene si tratti più di un problema di progettazione dello schema, non di un problema DBMS)
Requisiti di archiviazione dei dati

L'utilizzo del database da parte dell'applicazione è quello più critico.Principalmente quali query vengono utilizzate più spesso (SELECT, INSERT o UPDATE)?

Supponiamo che se usi SQLite, è adatto per applicazioni più piccole, ma per l'applicazione "web" potresti averne una più grande come MySQL o SQL Server.

Anche il modo in cui scrivi gli script e le piattaforme delle tue applicazioni web sono importanti.Se stai sviluppando su una piattaforma Microsoft, SQL Server è un'alternativa migliore.

In genere, seguo ciò che è comunemente accettato dal framework che sto utilizzando.Quindi, se sto eseguendo .NET => SQL Server, Python (tramite Django o Pylons) => MySQL o SQLite.

Però non uso quasi mai i file flat.

Nella scelta di una soluzione RDBMS c'è di più che semplicemente "potenza di back-end".La possibilità di avere il controllo del commit, ad esempio, in modo da poter ripristinare una transazione non riuscita è una di queste.motivo.

A meno che non si utilizzi l'applicazione con tariffa per megatransazioni, la maggior parte dei motori di database sarebbe adeguata, quindi diventa una questione di quanto si desidera pagare per il software, se funziona sull'hardware e sull'ambiente del sistema operativo desiderati e quali competenze si hanno nella gestione di quel software.

Quella progressione sembra dolorosa.Se intendi includere prodotti MS (in particolare SQL Server a pagamento) ovunque, puoi anche utilizzare l'intero stack, poiché devi pagare solo per l'ultimo di questi:

SQL Server Compact -> SQL Server Express -> SQL Server Enterprise (clustered).

Se inizialmente indirizzi la tua app a SQL Server Compact, è garantito che tutto il codice SQL verrà aggiornato alla versione successiva senza modifiche.Se diventi più grande di SQL Server Enterprise, congratulazioni.Questo è quello che chiamano a Bene problema da avere.

Anche:torna indietro e controlla i podcast SO.Credo che ne abbiano parlato brevemente.

Questa domanda dipende davvero dalla tua situazione.

Se hai il controllo sul server su cui stai distribuendo e puoi installare tutti i servizi di cui hai bisogno, allora il tempo necessario per installare un server MySql o MSSQL Express e codificare su un framework di database esistente RISPETTO alla codifica su una struttura di file flat non vale lo sforzo di considerare.

E che dire di FireBird?Dove si adatterebbe a quella lista?

E non dimentichiamoci dei requisiti che deve avere anche il “cliente” della vostra soluzione.Se stai scrivendo un'applicazione commerciale per una piccola azienda, Oracle potrebbe non essere una buona scelta...ma se stai scrivendo una soluzione personalizzata per una grande azienda che deve condividere dati tra più campus e dispone di un reparto IT di buone dimensioni, la decisione di Oracle vs Sql Server si ridurrà a ciò che molto probabilmente il cliente ha già implementato.

La migrazione dei dati al giorno d'oggi non è poi così male dato che disponiamo degli ottimi strumenti di Embarcadero, quindi lascerei invece che siano le esigenze del cliente a guidare la decisione.

Se hai l'opzione SQL Server è una buona scelta fin dall'inizio, soprattutto perché hai accesso a procedure e funzioni solide e le strutture di backup del database sono totalmente affidabili.Raggiungere quanta più logica possibile all'interno del database stesso (piuttosto che in qualsiasi linguaggio si stia utilizzando) aiuta la sicurezza e le prestazioni - in effetti c'è una buona argomentazione da sostenere per utilizzare sempre le procedure per la logica di inserimento/aggiornamento poiché queste ti fanno invulnerabile agli attacchi di iniezione.

Se posso scegliere, l'unica volta che prenderei in considerazione MySQL è con un database ampio, abbastanza semplice, utilizzato prevalentemente per l'accesso in lettura.Questo non è per denigrare MySQL che è migliorato notevolmente negli ultimi tempi e che utilizzo volentieri se non ho scelta, ma per sistemi più complessi con attività di aggiornamento/inserimento MSSQL è generalmente l'opzione superiore.

Penso che la tua lista sia soggettiva, ma starò al tuo gioco.

File piatti

BDB

SQLite

MySQL

PostgreSQL

server SQL

Oracolo

Teradata

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow