Per i dati definiti dall'utente, è meglio usare una tabella di tabelle o tabelle create dinamicamente?

Un design generico del database limita la proliferazione di nuove tabelle man mano che aumenta il numero di moduli e di elementi di dati. D'altra parte anche la query più semplice riguardava 3 tabelle, nel nostro caso.

Le query in effetti sono state davvero sconvolgenti. Dopo 3 anni di questo sono diventato dell'opinione che i tavoli espliciti erano migliori. Preferirei trattare più tabelle che riflettessero meglio la forma / modello di business - che posso capire solo guardandole; vizio 1/2 delle tabelle ma con moltitudini di tabelle di join prive di significato che richiedono interrogazioni lunghe e annidate stupefacenti per rendere anche il senso più rudimentale dei dati. In realtà inizi a memorizzare il significato / contesto delle singole chiavi primarie della colonna di identità!

Infine, ci siamo evoluti verso il punto in cui avevamo una tabella per domarli tutti in modo da allontanarci da alcune delle complessità intrinseche (e dalle cattive decisioni di codifica e progettazione del passato) nel design esistente e requisiti degli utenti in evoluzione. Ciononostante, eravamo certi che avremmo avuto problemi in quanto le dimensioni della tabella andavano alla dimensione di milioni + righe.

Vantaggi della tabella "table": più semplice per scrivere query, tempi di sviluppo più rapidi, probabilmente non dovresti avere a che fare con funzionalità complicate, poiché ciò sarebbe aggiunto dai programmatori, non dagli utenti.

Contro tabella "tabella" - Il database non può vedere le tabelle "reali" in modo che non possa validare, ottimizzare o indicizzare molto bene.

Contro tabelle dinamiche - Ugh, scrivere query dinamiche è un dolore gigante .

Se le tabelle definite dall'utente non sono correlate tramite FK, è possibile prendere in considerazione l'idea di trattare tali "tabelle definite dall'utente" come fogli di calcolo (o fogli di calcolo). Puoi presentarli come una griglia e memorizzarli come file CSV o convertirli in un tavolo. Questo approccio renderebbe la vita più facile per lo sviluppatore e per l'utente poiché l'utente avrà familiarità con i fogli di calcolo (presumo). Nel mondo .NET ci sono molti strumenti che ti danno l'aspetto e il layout del foglio di lavoro.

Personalmente cerco di fare un buon lavoro nel definire le esigenze dei dati che i campi e le tabelle definiti dall'utente non sono necessari. Se non hai definito il 98% di ciò di cui avrebbero bisogno, nella maggior parte dei casi ciò significa che non hai fatto il tuo lavoro. Esistono poche esigenze reali per quel tipo di flessibilità (i test di laboratorio vengono in mente dove vengono continuamente scoperti nuovi con esigenze molto diverse).

Nel caso in cui ne avessi bisogno, sceglierei prima una tabella con 5 o 6 colonne di base più il client_id per unirmi ad altre cose che il client potrebbe definire come qualcosa di significativo per loro. Le query utilizzerebbero il nome generico e avresti impostato in qualche modo l'effettiva corrispondenza di un'etichetta alla colonna. Potresti persino avere una tabella definita dal client per ogni funzione principale, quindi potresti unirti alla tabella degli ordini su orderid e ottenere i campi client_defined. E hanno cinque o sei campi disponibili per gli utenti, ecc.

Almeno in questo modo le query vengono scritte in anticipo. Il vantaggio è che si ottengono così tanti campi definiti dal cliente, ma onestamente nella maggior parte delle situazioni nessuno ne definirà uno o ne faranno solo uno o due a meno che non si sia fatto un lavoro orribile nel design originale. È la mia esperienza che gli utenti amano dire che vogliono quella flessibilità, ma odiano effettivamente usarla perché li confonde. Addizionalmente ogni programma COTS che ho mai usato che è stato venduto per la sua flessibilità era un incubo da usare e rallentare piuttosto che lentamente, quindi trovo che la flessibilità sia ampiamente sopravvalutata.

La mia ultima scelta sarebbe una tabella EAV poiché sono lente e difficili da interrogare. Se davvero avessi davvero bisogno di quella funzionalità perché in effetti molte cose definite dal cliente non erano solo possibili ma probabili, considererei l'utilizzo di un database nosql per quella parte dell'applicazione. Almeno nosql sono ottimizzati per utilizzare al meglio le strutture EAV. Non c'è motivo per cui non possano essere combinati con database relazionali nella stessa applicazione.

Vorrei chiaramente approfittare del DBMS che sto usando. Vorrei mappare i tipi di dati che offro ai tipi di dati DBMS e creare dinamicamente tabelle 1 a 1 reali nel DBMS (probabilmente con un sistema di prefissi di nomi di tabelle in base alle esigenze prevedibili). Quindi, è possibile avere definizioni di tabelle semplificate da qualche parte (un'altra tabella, forse), che descrivono le tabelle utilizzando il sottoinsieme di tipi di dati e / o SQL che si è scelto di utilizzare. Queste definizioni semplificate verrebbero utilizzate per descrivere le tabelle dell'applicazione frontend, creare i moduli, formattare i risultati della query, ecc. Penso che più grande è il sottoinsieme, migliore è l'applicazione che si può ottenere, ma anche il più complicato. Ci sto davvero pensando in termini di un'interfaccia tra ciò che offri ai tuoi utenti e il DBMS.

Per prestazioni e flessibilità, starei vicino al DBMS. Probabilmente non desideri veramente ottimizzare le query multi-vincolo a più tabelle da te stesso e ri-implementare chiavi, vincoli, ecc. Puoi ancora fornire funzionalità apparentemente diverse agli utenti. La parte difficile è pensare l'architettura in modo che il codice non diventi troppo complicato da usare / mantenere e non ridurre troppo il sottoinsieme di funzionalità.

Alla fine, dipende anche dai reali requisiti di flessibilità e prestazioni.