Quando abbiamo iniziato la nostra applicazione abbiamo avuto la scelta di andare con il tradizionale database normalizzato MS-SQL o con un database NoSQL (RavenDB è ciò che abbiamo provato). Ecco una versione semplificata del nostro schema:
<Order OrderNumber="1000" OrderVersion="1" ...>
<Products>
<Product Code="X58" Price="$5.50" Quantity="3" ... />
<Product Code="X70" Price="$9.99" Quantity="1" ... />
</Products>
<Contacts>
<Contact ... />
<Contact ... />
</Contacts>
</Order>
Anche se avremmo potuto utilizzare un database MS-SQL, non lo abbiamo fatto perché volevamo che tutti i nostri dati per un ordine fossero conservati storicamente; non volevamo contattare il contatto, anche se avevano lo stesso nome e indirizzo perché, mentre potrebbe cambiare, l'ordine dovrebbe avere le informazioni di contatto al momento dell'acquisto . Inoltre, sì, potremmo avere i nostri prodotti FK invece di utilizzare il codice per fare riferimento al prodotto, ma i prodotti non vengono mai eliminati, e ancora ... se sono aggiornati, vogliamo acquisire le loro informazioni al tempo di acquisto . Fondamentalmente, ogni Ordine sembra essere un documento autonomo che non dovrebbe mai contare su FK.
OrderVersion serve solo per tenere traccia della nostra versione del processo quando l'ordine è stato creato, potremmo facilmente aver utilizzato OrderDate per monitorare il controllo delle versioni.
Comunque, quindi la nostra decisione era di andare con RavenDB. Abbiamo creato la nostra applicazione e il nostro sito web, e internamente lo stiamo testando. L'unico scenario a cui stiamo imbattendo in problemi è: "Come fai un aggiornamento collettivo su record buono come SQL?"
Ad esempio, se avessimo appena spinto il nostro codice in produzione durante la manutenzione offline e in qualche modo tutti i record da MA con codici postali che hanno uno zero iniziale (0) avevano lo zero tagliato (ovvero il codice postale ora leggeva 1234 invece di 01234 )?
Normalmente, applicheremo le patch immediatamente su un server fail-over alla volta e l'aggiornamento dei record sarebbe facile:
UPDATE c
SET c.ZipCode = ...
FROM Contact c
INNER JOIN Order o ON c.OrderId = o.OrderId
WHERE o.Version = 1
AND ...
Tuttavia, sembra che la migliore soluzione che potremmo trovare se usiamo RavenDB è quella di ottenere tutti i documenti, quindi aggiornare i record a livello di codice tramite un'app personalizzata per console C #. Sembra che TSQL sia molto più facile / veloce. Non sono sicuro se ci sia un modo migliore di cui non siamo a conoscenza, o si tratta di un difetto comune nell'uso di RavenDB (o di qualsiasi archivio di documenti NoSQL)?
La mia più grande preoccupazione è che, mentre la nostra app per console sembrava funzionare abbastanza bene con un campione di ordini da 100 K, cosa succede se arriviamo al punto di 50 milioni di ordini !? Oppure, è anche un problema con T-SQL che alla fine dovremmo incontrare con l'esempio che ho dato?