L'uso di mongodb migliora l'estensione / modifica delle applicazioni basate su database?

4

Quando viene creata un'applicazione che richiede di archiviare dati, viene utilizzato molto spesso un database SQL. Così ho fatto in molte applicazioni di asp.net. Le applicazioni risultanti hanno spesso un ORM come il framework di entità e forse un livello aziendale.

Quindi, quando una tale applicazione deve essere estesa (diciamo che è necessario aggiungere una proprietà di commento a un oggetto), è necessario modificare / estendere il database, quindi l'ORM e il livello aziendale e così via. Per distribuire le modifiche è necessario aggiornare il database di destinazione e l'applicazione. So che cose come il codice prima e fluente possono rendere questo approccio più semplice.

Ho provato mongodb, ho usato solo il driver standard e ho dovuto estendere alcuni oggetti e tutto quello che dovevo fare era cambiare il codice.

Quindi ritiene che tali approcci siano molto più facili da realizzare quando si utilizza mongodb. Non ho molta esperienza con le applicazioni più grandi un mongodb. So che un database SQL o mongodb non si adatta a tutte le esigenze ed entrambi hanno i loro pro e contro.

Voglio sapere se il mio sentimento è giusto, se sì, sceglierei piuttosto scegliere mongodb che database SQL.

    
posta developer10214 01.11.2013 - 19:22
fonte

2 risposte

3

Trovo che semplifichi le cose nello sviluppo iniziale, ma una volta che si arriva al supporto della produzione, le cose diventano più difficili. Certo, quando il modello di dati cambia, cambi semplicemente il tuo codice, ma cosa fai con i dati in Mongo che usano ancora il vecchio formato? È necessario scrivere uno script di aggiornamento del modello di dati in modo molto simile allo script di modifica dello schema SQL oppure l'applicazione deve gestire ogni versione del modello di dati che sia mai esistita.

    
risposta data 01.11.2013 - 22:10
fonte
2

No, non è più semplice estendere / modificare l'applicazione scegliendo mongodb, perché hai ancora un meccanismo di archiviazione abbinato alla tua logica. La scelta rimescola il mazzo, alcune modifiche diventano più facili di un RDBMS, altre diventano più difficili.

Inoltre, potrebbe non essere saggio selezionare un meccanismo di archiviazione basato sulla possibilità di estendere / modificare l'applicazione, in quanto questa strada potrebbe portare a:

  • Prendere una decisione sull'archiviazione dei dati senza una valutazione dei problemi di archiviazione (la domanda elenca solo i problemi di sviluppo).

  • Accoppiare l'applicazione a questa scelta, rendendo più difficile cambiare se la scelta non è corretta.

Se la tua caratteristica è questa: "Un utente dovrebbe essere in grado di commentare un oggetto", quindi potresti voler esaminare perché l'implementazione dipenderebbe da dove è stato archiviato l'oggetto. Questa funzione non dovrebbe funzionare allo stesso modo se l'oggetto è in memoria, in un file, sulla luna o altrove?

Tutto ciò che serve è un'interfaccia di archiviazione per l'oggetto e i commenti. A quel punto, è possibile memorizzare gli oggetti in memoria per eseguire i test, quindi scegliere di implementare un adattatore RDBMS, un adattatore noSQL, entrambi o nessuno dei due, in base alle esigenze di archiviazione e non necessariamente ai tempi di sviluppo.

    
risposta data 02.11.2013 - 00:45
fonte

Leggi altre domande sui tag