Come implementeresti un "tavolo" molto ampio?

Question

Diciamo che stai modellando un'entità che ha molti attributi (2400+), molto maggiore del limite fisico su un determinato motore di database (ad esempio ~ 1000 SQL Server). Non sapendo nulla dell'importanza relativa di questi punti dati (quali sono i più caldi/usati più spesso) oltre alle chiavi dominio/candidato, come vorresti implementarlo?

A) EAV. (boo ... Strumenti relazionali nativi buttati fuori dalla finestra.)

B) Andare dritto. La prima tabella ha una chiave primaria e 1000 colonne, fino al limite. La tabella successiva è 1000, estraneo con chiave per il primo. L'ultimo tavolo è il rimanente 400, anche con chiave esterna.

C) Striscia uniformemente tra le tabelle ceil(n/limit). Ogni tabella ha un numero pari di colonne, chiave esterna per la prima tabella. 800, 800, 800.

D) Qualcos'altro ...

E perché?

Modifica: Questa è più una questione filosofica/generica, non legata a limiti o motori specifici.

Modifica^2: come molti hanno sottolineato, i dati probabilmente non sono stati normalizzati. Come al solito, i vincoli commerciali all'epoca rendevano impossibile la ricerca approfondita.

Answer 1

La mia soluzione: approfondire. In particolare, stabilire se la tabella è veramente normalizzata (a 2400 colonne questo sembra altamente improbabile).

In caso contrario, ristrutturare fino a quando non è completamente normalizzato (a quel punto è probabile che ci siano meno di 1000 colonne per tabella).

Se è già completamente normalizzato, stabilire (per quanto possibile) le frequenze approssimative della popolazione per ciascun attributo. Posizionare gli attributi più comuni sulla tabella "home" per l'entità, utilizzare 2 o 3 tabelle aggiuntive per gli attributi meno frequentemente popolati. (Provare a fare in modo che la frequenza di occorrenza i criteri per determinare quali campi dovrebbero andare su quali tabelle.)

Considerare EAV solo per attributi estremamente scarsamente popolati (preferibilmente, per niente).

Answer 2

Senza avere molta conoscenza in questo settore, penso che un'entità con così tante caratteristiche abbia davvero bisogno di una riprogettazione. Con ciò intendo suddividere la grande cosa in parti più piccole che sono logicamente connesse.

Answer 3

Vorrei ruotare le colonne e renderle righe. Piuttosto che avere una colonna che contiene il nome dell'attributo come una stringa (nvarchar), si potrebbe avere come una chiave di accesso a una tabella di ricerca che contiene un elenco di tutti i possibili attributi.

Ruotando in questo modo significa:

• non hanno masse di tabelle per registrare i dettagli di un solo elemento
• non hanno tabelle massicciamente ampio
• È possibile memorizzare solo le informazioni necessarie a causa della rotazione (se non si desidera memorizzare un particolare attributo, poi basta non hanno quella riga)

Answer 4

userei un uno a molti tabella degli attributi con una chiave esterna all'entità.

Eg

entità: id,

attrs: id, ENTITY_ID, attr_name, valore

AGGIUNTO

O come Butler Lampson direbbe, "tutti i problemi in Computer Science possono essere risolti da un altro livello di riferimento indiretto "

Answer 5

1. Guarderei molto attentamente il modello di dati . E 'il 3 ° normale modulo ? Ci sono gruppi di attributi che dovrebbero essere logicamente raggruppati insieme nelle proprie tabelle?

2. ammesso che sia normalizzata e l'entità ha veramente 2400+ attributi, io non sarei così pronta a fischiare un EAV model. IMHO, è la soluzione migliore, più flessibile per la situazione che hai descritto. Fornisce supporto integrato per dati sparsi e offre una buona velocità di ricerca in quanto i valori per ogni attributo dato possono essere trovati in un singolo indice.

Answer 6

La voce chiave per me è questo pezzo:

sapendo nulla circa l'importanza relativa di questi punti di dati (quali sono caldi/usato il più delle volte)

Se hai un'idea di quali campi sono più importanti, metterei quei campi più importanti nella tabella "nativa" e lasciare che una struttura EAV gestisca il resto.

Il fatto è che, senza queste informazioni si sta veramente girando cieca in ogni caso. Sia che abbiate 2400 campi o solo 24, dovreste avere qualche idea sul significato (e quindi sull'importanza relativa, o almeno sui raggruppamenti logici) dei vostri punti dati.

Answer 7

Usa Sparse Columns per un massimo di 30000 colonne. Il grande vantaggio rispetto a EAV o XML è che è possibile utilizzare Filtered Indexes in combinazione con colonne sparse, per ricerche molto efficienti su attributi comuni.

Answer 8

desidero utilizzare verticale (aumento del numero di righe) avvicinamento anziché orizzontale (aumentare il numero di colonne).

Si può provare questo approccio come

Tabella - id, nome_proprietà - property_value.

Il vantaggio di approccio è, non è necessario modificare/creare una tabella quando si introduce la nuova proprietà/colonna.