Consentire agli utenti finali di aggiungere dinamicamente colonne a una tabella

Question

Stiamo sviluppando un'applicazione .NET con un back-end di SQL Server. Il client richiede la possibilità di aggiungere in modo dinamico attributi personalizzati alle entità dopo che l'applicazione è stata distribuita.

Come suggerito in a similar question, è possibile creare una tabella che conterrà quindi una riga per ogni valore di attributo personalizzato (modello Entity-attribute-value). Tuttavia, stiamo considerando di consentire agli utenti finali di modificare effettivamente la tabella (also suggested nella stessa domanda), ad esempio aggiungendo e rimuovendo colonne.

(Edit: come notato nei commenti, DDL non sarebbe stato eseguito direttamente dagli utenti o l'applicazione, ma attraverso le stored procedure per garantire che tutto fili liscio)

ragioni principali sono:

• Prestazioni migliorate/attributi ricercabili
• Gli attributi sono quasi sempre obbligati a comparire come colonne, ad es. in una griglia di dati nell'interfaccia utente o durante l'estrazione di dati per un'ulteriore elaborazione in Excel/PowerPivot.
• dati è fortemente tipizzato (al contrario di memorizzare tutti i valori degli attributi come varchar)
• Un modello di dati semplificato

Esistono avvertimenti che dovremmo essere a conoscenza?

Le cose che vengono in mente sono: operazioni che potrebbero essere in grado di gestire il cambiamento struttura dati

oggetti dipendenti (come ad esempio visualizzazioni) che non sono adeguatamente aggiornati per riflettere

• backup/ripristino questi cambiamenti (una vista dipendente dovrebbe eseguire un select * from table per includere eventuali colonne aggiunte).
• ...

Qualsiasi ingresso riguardo l'approccio è molto apprezzato.

Answer 1

Io lavoro con un'applicazione di terze parti che gestisce questo in una varietà di modi:

1. maggior parte delle tabelle hanno una versione 'personalizzata' del tavolo con diversi campi di tenere genericamente chiamati tipi di dati: numero1, Date26 , Testo3, ecc.). Quindi c'è Company and CompanyCustom che ha una relazione 1-1.

2. Gli elenchi vengono creati su una tabella che ha un ListID (e un modo corrispondente per gli utenti di configurare lo schema) e una chiave esterna per il collegamento a una tabella principale. Questa tabella ha diverse colonne generiche come # 1.

3. creare i propri tavoli

4. creare le proprie viste e stored procedure e registrarli nell'applicazione. Questi set di dati possono essere allegati a griglie di dati e/o utilizzati in report personalizzati.

C'è un'interfaccia per l'utente può etichettare le colonne come meglio credono (ad esempio Text1 = "Blah Blah Blah").Ci sono molti campi sprecati in questa situazione (anche se la mia azienda è riuscita a utilizzare la maggior parte dei campi incluso Money47) e non è l'ideale per le prestazioni, non si può battere la flessibilità quasi illimitata che abbiamo.

La chiave qui è quanto questo cliente è disposto a pagare per questa capacità insieme al supporto in corso? Se gli permetti di creare campi personalizzati su una tabella esistente e decidono di voler cambiare il tipo di dati che non si convertono facilmente, ti aspetteranno che tu li misuri e li converta?

Potremmo assumere un programmatore a tempo pieno per quello che paghiamo per questo sistema. SalesForce.com e siti simili hanno questa capacità. Non penso che tu voglia entrare in questo per un'app client unica. Possono anche pagare per mantenere l'aggiornamento dell'app a lungo termine.