Come calcolare il livello dati in nopCommerce e sostituire MS SQL con RavenDB?

Ho provato sia MongoDB che RavenDB per il DB di NopCommerce. Tuttavia, come ha detto Matt, non è una buona idea. Ecco alcuni motivi:

1. La via più breve è il pattern di repository, un anti-fan di RavenDB. Mi ci sono voluti circa 2 settimane.
2. La funzione di ricerca di Nop è ottimizzata per SQL. Raven può farlo meglio e più bello, ma devi cambiare molti metodi di Nop.
3. Tutte le funzioni di cercapersone e di ordinamento verranno riscritte. Per cambiare il livello dati, dovrai cambiare anche metà del livello aziendale!

Ho lavorato con entrambi, e mentre è possibile non è certamente raccomandato.

I sistemi progettati su database relazionali raramente possono essere convertiti direttamente su database non relazionali. Esistono molti modelli diversi da utilizzare per raggiungere l'efficienza.

Ad esempio, in un database relazionale, potresti avere due tabelle che sono unite con una relazione uno-a-molti, come un Ordine e i suoi OrderLineItems. Questo è molto comune nella progettazione di database relazionali. Tuttavia, è completamente indesiderato in un database di documenti come RavenDB. Invece, modellerai un intero documento con tutti i suoi figli come un'unica "Radice aggregata". Un ordine e tutti i suoi OrderLineItems sarebbero in un unico documento.

Cambiare i motori di archiviazione tramite un'interfaccia repository può sembrare una buona idea, ma in pratica uno di solito lo trova poco pratico.

Ora prima come posso conoscere gli interni di nopCommerce (oltre a investigare il codice)? Sono i flussi di lavoro? È convenzioni?

Bene, c'è sempre la documentazione, ma non c'è davvero modo migliore di leggere il codice sorgente. Il codice sorgente nopCommerce è organizzato abbastanza bene, quindi non dovrebbe essere troppo difficile.

Secondo qualcuno qualcuno ha provato qualcosa di simile prima con un database NoSQL (come MongoDB o RavenDB)? È possibile ottenere questo in un intervallo di tempo di 1 (~ 2) mesi?

Non ho provato questo, né conosco nessuno che lo abbia. Tuttavia, solo uno sguardo superficiale al codice mostra che la strategia di accesso ai dati è strutturata in modo piuttosto strong attorno al modello di repository utilizzando Entity Framework.

link

The Nop.Data project contains a set of classes and functions for reading from and writing to a database or other data store. It helps separate data-access logic from your business objects. nopCommerce uses the Entity Framework (EF) Code-First approach. It allows you to define entities in the source code (all core entities are defined into Nop.Core project), and then get EF to generate the database from that. That's why it's called Code-First. You can then query your objects using LINQ, which gets translated to SQL behind the scenes and executed against the database.

Direi che la conversione in un back-end NoSQL richiederebbe probabilmente uno sforzo significativo. Ci sono stati altri post di SO che discutono sull'utilizzo di RavenDb con il modello di repository. Può essere fatto? Sicuro. Può essere fatto in un mese o due? Forse, ma è impossibile dirlo senza conoscere molti dettagli della tua situazione specifica.

Whoa, rallenta, non cambi mai solo un database. Ciò è estremamente rischioso, specialmente se il database è già in produzione. E la conversione da relazionale a nosql può richiedere molto tempo in quanto le cose non corrispondono esattamente. La tua ragione sembra essere che preferisci quella a cui sei abituato e che è una ragione orribilmente invalida per la quantità di rischio che stai assumendo convertendo il database.

Né si tratta di una domanda per estranei su Internet, se si propone di fare una cosa del genere, i vostri dirigenti aziendali hanno bisogno di sapere in anticipo e con molte discussioni sul tempo e il rischio e i benefici. È NON la tua chiamata, è una decisione di gestione.

Inoltre, è necessario determinare se è necessario convertire i dati esistenti e cercare eventuali altri elementi che potrebbero utilizzare il back-end del database oltre alla propria applicazione, ad esempio la segnalazione di applicazioni o l'importazione di dati. Potrebbe anche essere impostato in modo specifico per seguire le regole richieste dai revisori dei conti o dai processori delle carte di credito e che potrebbero impedire l'uso di nosql.

Non vorrei nemmeno convertire il database Oracle nel server SQl o viceversa senza almeno un anno nel piano del progetto e tanto meno convertire da relazionale a non-relazionale.

Tuttavia, considera che la nuova funzionalità potrebbe utilizzare l'approccio nosql se è stato approvato in anticipo, per cose che non possono essere facilmente definite in anticipo. Non vi è alcuna regola che un progetto non possa utilizzare entrambi i nosql quando appropriato e relazionale quando appropriato.