NoSQL in SQL Server

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

Abbiamo iniziato da zero un nuovo progetto utilizzando MVC5, Entity Framework 6 code e SQL Server 2008. Quando l'architetto ha riesaminato lo schema del database, ha affermato che tutte le chiavi esterne e altri vincoli di questo tipo devono essere rimossi poiché si tratta di "logica aziendale" e dovrebbe essere applicato all'interno del livello aziendale del codice dell'applicazione.

La mia opinione è che le chiavi esterne fanno parte dei dati / integrità referenziale e non imitano realmente la logica aziendale. Vedo la logica aziendale come più il processo e la convalida che controlla cosa / quando / come / perché vengono applicati i riferimenti. Riesco a capire che i vincoli univoci sono probabilmente processi aziendali, ma per me questo completa la logica e fa parte dell'integrità.

Un secondo argomento è l'obiettivo è quello di adottare un approccio NoSQL ai dati. L'ho trovato davvero insolito e poco ortodosso: considerando l'uso di SQL-Server 2008, la necessità di creare report, i dati non scalabili in terabyte e la mancanza di considerazione verso tecnologie come Mongo, Raven, ecc.

Qualcuno ha mai visto uno scenario simile prima? Perché qualcuno dovrebbe adottare un approccio NoSQL in un SQL Server progettato per dati referenziali e non desiderare chiavi esterne?

sql sql-server nosql

— Andy Clark
fonte

Parla con il tuo architetto di sistemi della logica dei suoi consigli. O ha un ottimo motivo che si applica al tuo caso specifico (un motivo che non saremo necessariamente in grado di indovinare, senza sapere esattamente in cosa consiste la tua app), oppure è semplicemente incompetente.

— Arseni Mourzenko,

Ho visto implementare molti database in modo simile: nessun FK, nessun vincolo CHECK - ogni volta che erano database progettati da programmatori inesperti che non sapevano nulla dell'architettura del database, dell'integrità referenziale, ecc. Ma è importante per te discuterne con il tuo collega, invece di supporre che sia incompetente.

— Arseni Mourzenko,

Sono leggermente confuso; menzionate l'utilizzo di Entity framework (prima il codice) ... ciò non implica che create Oggetti (in senso C #) e poi lasciate che Entity framework gestisca la costruzione degli equivalenti del database, nel qual caso il tentativo di aggiungere / rimuovere FK ecc. è un esercizio nel tentativo di superare in astuzia Entity Framework (che è un po 'come la citazione di Mark Twain sul tentativo di insegnare a cantare un maiale?)

— Foon

Ci sono troppe persone che si dichiarano "architetti", ma in realtà non hanno esperienza nella codifica o nella manutenzione di sistemi più grandi.

— Doc Brown,

Rilevante: thedailywtf.com/articles/The-Mythical-Business-Layer . "Se ci pensate, praticamente ogni riga di codice in un'applicazione software è una logica aziendale". Questo si estende al database. "Ma è altrettanto importante - se non di più - tenere presente che quasi tutto il codice di un'applicazione sarà una logica aziendale. Ci sono già abbastanza strumenti là fuori; la tua applicazione non ha bisogno di un livello generico " (sottolineo il mio). La persona che raccomanda questo sta probabilmente provando a trasformare il database in uno di questi livelli generici. In breve, molto probabilmente stanno mettendo le parole d'ordine al di sopra della realtà.

— jpmc26

Risposte:

Quando ha esaminato lo schema del database, ha dichiarato che tutte le chiavi esterne e altri vincoli simili dovrebbero essere rimossi poiché si tratta di una logica aziendale e dovrebbero essere applicati all'interno del livello aziendale.

Quindi è un idiota e un estratto del tuo codebase probabilmente finirà un giorno su The Daily WTF . Hai assolutamente ragione sul fatto che il suo approccio non ha senso, e francamente non ha nemmeno la sua spiegazione.

Prova a spiegargli che i vincoli di integrità referenziale non sono "logica aziendale"; sono uno standard di correttezza con la propria verifica integrata. La logica aziendale riguarda ciò che fai con i dati; l'integrità consiste nel garantire che i dati stessi non siano corrotti. E se non funziona ... beh, è responsabile. Puoi seguire il suo piano e provare a mitigare un po 'il danno, oppure iniziare a cercare un posto migliore in cui lavorare. (O entrambi.)

— Mason Wheeler
fonte

Ho avuto una risposta leggermente più diplomatica che ha cercato di trovare una ragione (sana) per cui l'architetto potrebbe farlo. Riflettendomi in modo sobrio, mi prenderò invece cura di questa risposta.

— Blrfl

Whoa whoa, i cattivi tentativi di architettura sono un motivo per andare a lavorare altrove? Dannazione, non avrei mai potuto continuare a lavorare da nessuna parte se avessi preso quella prospettiva.

— Kzqai,

@Kzqai c'è anche l'architetto che fondamentalmente fraintende l'architettura. Questo inizia a suonare come la direttiva 595 e sì, se qualcuno volesse costringermi a usare i martelli per mettere le viti in un pezzo di legno, troverò qualcuno che non mi costringe a usare impropriamente gli strumenti per costruire qualcosa.

L'integrità referenziale è un argomento centrale nella teoria dei database, per non parlare di tutti i database che lo supportano nel mondo reale. Chiaramente il collega di Andy ha ragione nella sua analisi, il resto del mondo accademico e professionale ha torto al 100%. Punti bonus per la menzione del Daily WTF .

@AndyClark Dovresti smettere di farlo. Il motivo è che è una bomba a orologeria nucleare nel cuore della tua azienda. È solo una questione di tempo in cui la materia fecale colpisce il ventilatore. Quando ciò accade, saresti fortunato a lavorare per un turno di 72 ore, nel peggiore dei casi potresti cercare un lavoro ... meglio cercare un lavoro quando hai un reddito.

— Art

Devo ancora avere un motivo per creare una chiave esterna

- Joel Spolsky

Dichiarazioni generali a parte, vale la pena riconoscere che ci sono ragioni legittime e forti per scegliere di non usare unicità o vincoli di chiavi esterne. Molti vanno in questo modo:

Prestazione. Fare controlli di integrità con transazioni atomiche non è gratuito. E spesso, il database è la parte più difficile dell'architettura da ridimensionare. Forse esegui già i controlli nella logica dell'applicazione e preferiresti non incorrere in un secondo hit delle prestazioni.
Mancanza di necessità Forse i tuoi dati sono sporchi e tu sei d'accordo. Questo dipende molto da quello che stai facendo.

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

Ma quelli non corrispondono ai motivi della tua domanda.

Questa è la logica aziendale e deve essere applicata all'interno del livello aziendale.

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ò avvicinarsi alle garanzie di atomicità e integrità di SQL Server. Se hai bisogno di una forte integrità dei dati, saresti sciocco a ignorare il database.

Un secondo argomento è che vogliono adottare l'approccio NoSQL per la loro memorizzazione dei dati e quindi non vogliono che tali restrizioni vengano applicate.

Il secondo motivo non è in realtà un motivo; è una conclusione. Anche se è vero che i vincoli sono un compromesso tra correttezza e prestazioni, e i database NoSQL sono orientati verso quest'ultimo.

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

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

PS Se si conclude che non si desidera chiavi esterne, è comunque possibile utilizzare un database relazionale. Come generalizzazione, i database relazionali sono più maturi rispetto alle loro controparti NoSQL. Come singolo nodo, possono anche essere più veloci e su di essi può essere costruita un'astrazione NoSQL .

— Paul Draper
fonte

Oserei dire che Joel non è un idiota, ma una risposta arguta in un podcast, senza alcuna spiegazione è, IMHO, vale ancor meno di una dichiarazione di qualsiasi idiota.

— Martin Ba

Joel è un tipo di foglio di calcolo, non un tipo di database, quindi la sua ignoranza delle pratiche standard di database relazionali è, immagino, non sorprendente ... Senza offesa, Joel. :-)

— Eric King

La citazione effettiva nel contesto di Joel è che le tecnologie, come LINQ, forniscono un motivo per preoccuparsi di impostare una chiave esterna. Joel non è un amministratore di database e, cercando nel suo blog ed essendo un lettore di lunga data, non riesco a trovare nulla da lui che parli dell'argomento o cerchi di dare consigli sull'ottimizzazione dei database, sulla progettazione di modelli di dati, ecc. Joel è fantastico , ma non lo è ora né è mai stato - o ha affermato di esserlo! - un esperto nel settore dei database o della modellizzazione dei dati. È come citare Einstein sull'interesse composto - o, per quello, i sandwich. (Riferimento XKCD, prego.) :)

— BrianH

Joel Spolsky è noto per avere opinioni forti e controverse. Vedi FogBugz è scritto in un linguaggio proprietario ; L'iniezione di dipendenza è troppo complicata (a proposito, questa è stata la risposta più controversa su StackOverflow prima di essere chiusa) ; I database XML sono lenti ; ecc.

— BlueRaja - Danny Pflughoeft

@BlueRaja: Umm ... I database XML sono lenti, in particolare rispetto ai database relazionali. Da quando è controversa o un'opinione?

— Mason Wheeler