Quali alternative esistono quando una tabella richiede troppe chiavi esterne?

Disponiamo di una tabella di base che definisce le parti e contiene informazioni come il numero di parte, la descrizione, il prezzo, il peso, ecc. Abbiamo anche circa 400 tabelle che fanno riferimento alla tabella di base e forniscono informazioni aggiuntive sulle parti in base al loro tipo / categoria.

Abbiamo iniziato utilizzando i vincoli di chiave esterna in modo che una parte non potesse essere eliminata dalla tabella di base se viene referenziata in una delle 400 tabelle specifiche della parte, ma abbiamo rapidamente raggiunto il massimo di 253 chiavi esterne consigliate per SQL Server 2005.

Esistono alternative alle chiavi esterne in questa situazione che garantiranno l'integrità dei dati? Non abbiamo riscontrato problemi di prestazioni durante l'accesso ai dati, ma l'aggiornamento di una parte esistente nella tabella di base non riuscirà poiché il piano di query è troppo complesso.

sql-server-2005 foreign-key

— jellomonkey
fonte

Pensi davvero di aver bisogno di 400 tabelle specifiche per parte? Quanto sono diversi ciascuno di questi tavoli, davvero? Penso che stai cercando di riparare la parte sbagliata di questo disegno.

— Aaron Bertrand

Circa quante righe hai a che fare con questo database?

— Jon Seigel,

Devo essere d'accordo con Aaron Bertrand, se il tuo progetto richiede di massimizzare il supporto del server sql con chiavi esterne, potrebbe essere il momento di prendere in considerazione una riprogettazione.

— DForck42,

Ho realizzato molti progetti in questo settore: prezzi, gestione del prodotto, specifiche del prodotto. Anche in progetti altamente normalizzati, non mi sono mai avvicinato a così tanti FK sullo stesso tavolo. Stai forse facendo una sorta di strategia di partizionamento dei dati (per client o tempo o qualcosa del genere) che ti ha spinto a progettare in questa direzione? È difficile fornire una risposta senza ulteriori informazioni sul design e sugli obiettivi di progettazione.

— Karen Lopez,

Potresti fornire un esempio di schema per dire 5 di queste tabelle ...

— Damir Sudarevic

Risposte:

Se esiste un modo per raggruppare le parti, potresti essere in grado di introdurre tabelle intermedie come soluzione alternativa. Questo non funzionerà.

Parts
+ Table 1
+ Table 2
+ ...
+ Table 400

Ma qualcosa del genere potrebbe.

Parts
+ RedOrangeYellow parts
  + Table 1
  + Table 2
  + ...
  + Table 200

+ GreenBlueIndigoViolet parts
  + Table 201
  + Table 202
  + ...
  + Table 400

Vorrei dare un'occhiata al tuo DDL prima di consigliarlo , comunque. E se lo fai, non iniziare a lanciare numeri ID dappertutto. Dovresti essere in grado di unire "Tabella 400" direttamente a "Parti" senza includere "Parti GreenBlueIndigoViolet".

— Mike Sherrill 'Cat Recall'
fonte

Se davvero non riesci a combinare le tabelle, perché non crearne uno TRIGGERsulla tabella di base per impedire la cancellazione?

Inizia qui: http://msdn.microsoft.com/en-us/library/ms189799(v=sql.90).aspx

— Stu
fonte

-4

Sostituisci le oltre 400 tabelle con una. Sono necessari solo 3 campi (+1 autonumber o qualunque chiave primaria se lo si desidera, non è necessario averlo, è possibile formarlo dagli altri campi)

ID attributo ID oggetto

Quindi, dove nelle altre tabelle ogni campo rappresenta un attributo, in questa tabella i tuoi attributi sono tutti in un campo. Avresti qualcosa del genere

Valore dell'attributo ItemID

Materiale del calzino in lana

Calzino Colore Rosso

Peso del calzino 20 libbre

Alien Planet Alpha Centauri

Colore alieno viola

Alien Friendly No

Gli ItemID dovrebbero probabilmente essere un numero / offanumerico ofc. Quindi, basta incrociare i campi con Atrributes come intestazioni di colonna quando necessario per generare le tabelle come piace a te. Ciò consente anche di interrogare meglio cose come "Mostrami tutti gli oggetti di Alpha Centauri" che potrebbero restituirti l'Alieno e anche il frammento di meteorite che conteneva la piaga che spazza via l'umanità (sta arrivando .....)

L'ottimizzazione può essere complicata a seconda di quanti record ci sono, ma è un modo molto migliore per progettare questo. Ho fatto lo stesso per un database che conteneva un mucchio di ricette (10k +) che presentavano poche sovrapposizioni. Ha funzionato bene in quel caso. Non ho avuto problemi di velocità davvero. Il tuo potrebbe essere più difficile a seconda di quanti ne hai a che fare.

— user2125055
fonte

Questo si chiama Entity Attribute Value model ed è normalmente un'idea terribile per molte ragioni. Per il tuo esempio dello scenario "alpha centauri", dovresti esaminare probabilmente 2 scansioni di tabelle e non è possibile utilizzare gli indici. Inoltre, annulla qualsiasi vantaggio per i tipi di dati, rende impossibili i vincoli relazionali e generalmente non è ottimizzabile o scalabile in alcun modo. Se hai bisogno di memorizzare più di un centinaio di righe come questa, non farlo.

— JNK,

Come indica @JNK, di solito non è una buona soluzione. E peggio ancora quando lo fai con un solo tavolo. Direi che il minimo è di 3 tavoli ( Entity, Entity_Attribute, Entity_Attribute_Value). Se si desidera aggiungere un trattamento semi-corretto per tipi di dati e vincoli referenziali diversi, è necessario altro.

— ypercubeᵀᴹ

Mentre l'OP potrebbe avvicinarsi a un qualche tipo di limite con il tradizionale design normalizzato a causa della pura complessità delle entità nel loro sistema, i sistemi più complessi non sono realmente gestiti in modo migliore in EAV, poiché offre un supporto di tipo molto più debole e a livello di applicazione integrità referenziale poiché i dati sono tutti archiviati in modo abbastanza generico. EAV ha il suo posto utile, ma non sarei pronto a raccomandarlo come risposta a questo problema, come attualmente affermato.

— Cade Roux,

Huh, impara qualcosa di nuovo ogni giorno. Sono autodidatta ed è stato qualcosa che mi è venuto in mente per risolvere il problema con la ricetta che stavo avendo, il che sembra simile a questo problema di ragazzi. Ah bene. Grazie per le informazioni a riguardo, esaminerò EAV, forse c'è anche un modo più pulito per risolvere il mio problema. Potrebbe essere stato più facile per me poiché tutti i valori erano dello stesso tipo di dati. Non so.

— user2125055

@ user2125055 Non è un problema e non prendere personalmente nessuna critica. Stiamo solo ridimensionando l'idea di utilizzare EAV! Ci sono sicuramente casi d'uso in cui ha senso, ma a causa degli svantaggi devi stare molto attento.

— JNK,