Qual è la soluzione migliore? Per esempio. un oggetto ha molte impostazioni singole. Mantieni tutte queste impostazioni in una tabella o dividi queste funzionalità e archivia in tabelle separate con relazione 1: 1? Alcune funzioni sono necessarie per tutti gli oggetti, altri solo per tipi specifici di oggetti. Una soluzione potrebbe essere memorizzare tutti i campi richiesti negli oggetti tabella e il resto nella tabella objects_extras? "Oggetti" è solo un nome di esempio.
Some features are required for all objects, other only for specific types of objects. One solution could be store all required fields in table objects and the rest in table objects_extras?
Solo tu puoi decidere ciò, in base ai bisogni [dati] del tuo objectd.
Potresti rimanere con una tabella che include tutto, presumibilmente con voci nullable per quelle che non si applicano a tutti gli oggetti. È il più semplice e semplice da mantenere.
Oppure, si potrebbe andare con un progetto di "sottoclasse", con una tabella principale con tutte le cose comuni, oltre a un numero di altre tabelle "extra", una per ogni sottoclasse di oggetti. Non è molto più complesso da gestire, ma potrebbe darti alcuni benefici in termini di prestazioni se ogni sottoclasse ha un lotto di campi personalizzati (e non usi mai "seleziona *" nelle tue query ).
Oppure, puoi andare su extreme e andare in fondo alla strada (la tana del coniglio?) di Entity-Attribute-Value. Questo ti dà la completa flessibilità di quale proprietà va con quale oggetto, ma arriva al prezzo di [potenzialmente molto] scarso ridimensionamento, ma suppongo che sia ancora un'opzione.
Il mio suggerimento: prototipare ogni metodo e vedere come ognuno si sente.
Anche se il problema con una tabella con molte colonne in RDBMS era il duro limite del numero di colonne (guardando l'accesso dell'utente) nelle tabelle e un grande successo sull'uso del disco e della memoria.
Questi problemi non sono più così grandi, ma c'è ancora un grosso problema nella gestione del numero elevato di colonne nel codice. Oltre un minimo di 10-15 colonne in una tabella, la manutenzione può diventare un incubo a meno che non sia possibile nascondere il numero completo di colonne dietro un'astrazione (ORM, fatto in casa o framework).
Quando ti allontani dal dover sapere tutto di un tavolo ovunque lo usi, le cose diventano molto più semplici.
Esistono tre strategie sulle gerarchie di oggetti con attributi diversi ma alcune informazioni comuni.
Tabella per gerarchia:
Una tabella con tutte le colonne.
Tabella-per-tipo:
Una tabella di base ogni tipo ha una propria tabella con chiave esterna per la tabella di base.
Tabella-per-cemento-tipo:
Ogni tipo ha una propria tabella.
Questo è un articolo su come fare le cose in Entity Framework puoi trovare articoli simili basati su RDBMS o framework che vuoi usare.
Leggi altre domande sui tag design sql database-design