Migrazione di DB: mantenere i vincoli delle relazioni?

Question

A rischio di essere definito uno sciocco, mi chiedo quali sono i tuoi pensieri sul mantenimento dei vincoli relazionali all'interno di un DB SQL MS.

Sto migrando un sistema in un ambiente .NET da ASP. Questo porta con sé oggetti business e altre tecniche di codifica a più livelli, che lavorano per sottrarre il database dall'utente / API. La nuova applicazione ha un'API definita sopra un DAL Entity Framework.

Il database dell'applicazione nel vecchio database è grande e lo scopo di alcune tabelle cambierà per iniziare a contenere dati binari, sotto forma di file, ecc. Sono desideroso di dividerli in DB separati per facilitare gestione presso i siti client in cui lo spazio su disco è limitato.

Esiste un valore nel mantenere i vincoli di relazione tra le tabelle?

Ipotesi:

• Il codice è stato testato
• Laddove le relazioni sono importanti, l'esecuzione viene eseguita in una Transazione
• L'accesso al DB avviene solo tramite l'API, l'altro accesso da parte di terzi non è supportato.

Ragioni per mantenere i vincoli:

• Applica la struttura dei dati
• I JOIN sono più veloci?
• Assistenza per il piano di query?

Motivi per rimuovere i vincoli nella nuova versione .NET:

• Si può presumere che la logica API / BIZ gestisca relazioni come Parent / Child.
• Riduce l'opportunità di trasferire sezioni del DB in altri cataloghi (il sistema è costruito utilizzando un'architettura plug-in, la maggior parte delle tabelle può funzionare in modo isolato)
• Sono corretto nel ritenere che SQL debba fare ulteriori controlli durante INSERT sui vincoli, il che potrebbe essere inutile quando un'API sopra il DB lo sta gestendo?

Pongo comunque la mia domanda sulla comunità nel caso in cui mi sia perso qualcosa di stupido o se questo è solo un incubo in attesa di accadere ...

Mille grazie,

Nathan

Answer 1

Non sostengo l'affermazione secondo cui i vincoli "vengono indicizzati automaticamente". Solo le chiavi uniche e primarie lo fanno. Le chiavi esterne non lo fanno, sebbene nella maggior parte dei casi consiglierei di avere un indice su "figlio" abbinando le colonne dell'FK. Tuttavia consiglierei comunque FKeys come loro

1. applicherà l'integrità dei tuoi dati (ho morso troppe volte dal BL che ha bug e non riesce a fare il lavoro).
2. Fornisci all'ottimizzatore maggiori informazioni sul modello dei tuoi dati, che a sua volta potrebbe portare a piani di esecuzione migliori e più veloci.

Ma soprattutto, hai pensato di conservare i tuoi dati in un singolo database, ma di separarli in più filegroup? Potresti raggiungere il tuo obiettivo una gestione dello spazio su disco più flessibile senza i problemi delle chiavi esterne che coprono più DB

Answer 2

Sì, consiglierei di mantenere i vincoli relazionali. Sicuramente devi gestirli nel tuo BLL, ma i vincoli migliorano anche le prestazioni perché vengono utilizzati dal pianificatore di query per gestire le query in modo più efficiente.

Vedi anche questa domanda: Le chiavi esterne sono davvero necessarie in un progetto di database?

Answer 3

Sì, dovresti avere vincoli di chiave esterna sulle tabelle a meno che tu non abbia un motivo specifico per non farlo. Anche se l'applicazione è stata testata, potrebbe non essere l'unica cosa che abbia mai scritto nel database. FK impone l'integrità referenziale sui dati provenienti da tutte le fonti.

Le chiavi esterne fungono anche da una sorta di strumento di documentazione informale per le relazioni nel database. Laddove gli FK sono presenti in un database, posso invertire lo schema con Visio (o qualsiasi altro strumento che supporti il ??reverse engineering) e vedere le relazioni. Il rilascio di chiavi esterne su un database in nome delle prestazioni è una tecnica comune utilizzata dagli ISV per offuscare il loro schema di database e ottenere maggiori entrate di supporto.

Se riesci a tracciare un problema specifico relativo alle prestazioni su una chiave esterna, potrebbe essere necessario rilasciare la chiave. È probabile che ciò accada solo su un numero limitato di chiavi su una o due tabelle specifiche ad alto volume. È anche sempre probabile che sia necessario su sistemi con volumi di transazione davvero elevati. Non c'è mai una scusa per non avere affatto chiavi esterne in un database.