NoSQL in SQL Server

Question

NoSQL in SQL Server

#1 da (74 voti)
#2 da (2 voti)

28

Questa domanda non riguarda la differenza tra SQL e NoSQL. Sto cercando alcune ragioni per qualcosa che in questo momento non ha senso per me (forse a causa della mia mancanza di comprensione o apprezzamento).

Abbiamo avviato un nuovo progetto da zero utilizzando MVC5, il codice Entity Framework 6 e SQL Server 2008. Quando l'architetto ha esaminato lo schema del database, è stato affermato che tutte le chiavi esterne e altri vincoli dovrebbero essere rimossi poiché questo è "business" logica "e dovrebbe essere applicata all'interno del livello aziendale del codice dell'applicazione.

La mia opinione è che le chiavi esterne fanno parte dell'integrità dei dati / referenziale e non imitano la logica aziendale. Vedo la logica aziendale più il processo e la convalida che controlla quali / quando / come / perché i riferimenti vengono applicati. Riesco a capire che i vincoli unici sono senza dubbio processi di business, ma per me questo semplicemente integra la logica e fa parte dell'integrità.

Un secondo argomento è l'obiettivo è adottare un approccio NoSQL ai dati. Ho trovato questo inusuale e poco ortodosso: considerando l'utilizzo di SQL-Server 2008, la necessità di generare report, i dati non scalati ai terabyte e la mancanza di considerazione verso tecnologie come Mongo, Raven, ecc.

Qualcuno ha mai incontrato un simile scenario? Perché qualcuno dovrebbe adottare un approccio NoSQL in un server SQL progettato per i dati referenziali e non desidera le chiavi esterne?

sql nosql sql-server

posta Andy Clark 30.03.2015 - 16:21

fonte

2 risposte

Leggi altre domande sui tag sql nosql sql-server

Che cosa significa Dijkstra quando raccomanda una padronanza eccezionalmente buona della propria lingua madre? [chiuso] I metodi concreti stanno scavalcando un odore di codice?

score 74 · Answer 1

When he reviewed the database schema he stated that all foreign keys and other such constraints should be removed as this is business logic and should be applied within the business layer.

Quindi è un idiota, e qualche estratto dalla tua base di codice rischia di finire un giorno su Daily WTF . Hai assolutamente ragione che il suo approccio non ha senso, e francamente nemmeno la sua spiegazione.

Prova a spiegargli che i vincoli di integrità referenziale non sono "business logic"; sono uno standard di correttezza con la propria verifica integrata. La logica aziendale riguarda ciò che si fa con i dati; l'integrità riguarda l'assicurazione che i dati stessi non siano corrotti. E se questo non funziona ... beh, è lui a comandare. Puoi seguire il suo piano e cercare di mitigare il danno, o iniziare a cercare un posto migliore dove lavorare. (O entrambi.)

score 2 · Answer 2

I've yet to have a reason to create a foreign key

-Joel Spolsky

A parte le affermazioni generali, vale la pena di riconoscere che ci sono motivi legittimi e forti per scegliere di non utilizzare i vincoli di unicità o chiavi esterne. La maggior parte va in questo modo:

Prestazioni. I controlli di integrità con le transazioni atomiche non sono gratuiti. E frequentemente, il database è la parte più difficile della tua architettura in scala. Forse stai già facendo i controlli nella tua logica applicativa, e preferiresti non incorrere in un secondo colpo di rendimento.
Mancanza di necessità. Forse i tuoi dati sono sporchi e tu stai bene con quello. Questo dipende molto da quello che stai facendo.

Vedi anche Cosa c'è che non va con le chiavi esterne?

Ma quelli non corrispondono ai motivi della tua domanda.

This is business logic and should be applied within the business layer.

Questo motivo è un po 'strano. Unicità e altri vincoli di integrità sono in gran parte il dominio di un database ACID. Il codice dell'applicazione non può accedere alle garanzie di atomicità e integrità di SQLServer. Se hai bisogno di una strong integrità dei dati, sarebbe sciocco ignorare il database.

A second argument is that they want to adopt the NoSQL approach to their data storage and so do not want such restrictions in place.

La seconda ragione non è davvero una ragione; è una conclusione. Anche se è vero che i vincoli sono un compromesso tra correttezza e prestazioni, e il database NoSQL è orientato verso quest'ultimo.

Forse il tuo architetto di sistema ha in mente queste ragioni legittime, e tu hai capito male. O forse è un idiota blaterante.

In ogni caso, ci sono valide (anche se non universali) ragioni per astenersi dall'usare univocità e vincoli di chiave esterna.

P.S. Se concludi che non vuoi le chiavi esterne, è ancora bene usare un database relazionale. Come generalizzazione, i database relazionali sono più maturi rispetto alle loro controparti NoSQL. Come nodo singolo, possono anche essere più veloce e un'astrazione NoSQL può essere costruita su di essi .