DB Design per front-end non statico

Question

DB Design per front-end non statico

#1 da (2 voti)
#2 da (0 voti)

1

Ho una domanda sulle migliori pratiche per progettare un database che deve contenere i seguenti dati:

C'è una pagina con un questionario che ha domande predefinite come Nome , Cognome , Via ... (50 altri campi). Ora le persone possono registrarsi alla pagina e aggiungere un altro campo personalizzato al questionario. Ecco la parte difficile: Questo campo è visibile solo sui moduli creati dalla persona. Altre persone dovrebbero vedere solo i propri campi personalizzati nei propri questionari.

Come è la migliore pratica progettare qualcosa del genere in un database? Posso immaginare due cose:

Crea una tabella per le risposte al questionario in cui ogni campo è una colonna. Aggiungi un'altra colonna per una stringa json che definisce i campi personalizzati ( nvarchar (max) ) e contiene la risposta di un cliente. Una tabella di secondi contiene ID di domande dell'utente e in una seconda colonna una stringa JSON che definisce i campi personalizzati.
Crea una tabella per i questionari del questionario predefinito in cui ogni campo predefinito è una colonna. Una tabella dei secondi contiene gli ID questionari dell'utente. Crea una terza tabella che contiene i campi personalizzati per ogni utente. Col1 ID utente , Col2 QuestionnaireID , Col3 QuestionName , Col4 QuestionType . In una quarta tabella le risposte dei client sono collegate alla tabella 3.

Probabilmente esiste un altro modo migliore?

database data-structures database-design tsql

posta serious 29.01.2016 - 11:48

fonte

2 risposte

Leggi altre domande sui tag database data-structures database-design tsql

Scala, verifica il tipo e quindi esegue il cast Come gestire i file uploads express (UUID / posizione)

score 2 · Answer 1

Dovresti considerare l'idea che le specifiche cambiano. Oggi ci sono 50 campi predefiniti, domani potrebbero esserci 51. Non vuoi aggiungere una colonna ogni volta che cambiano i requisiti. Il contrario potrebbe anche essere vero; cosa succede se una colonna non è più obbligatoria o non è più necessaria?

L'esempio ERD di seguito consente quanto segue:

le persone possono prendere un questionario più di una volta
le domande, sia predefinite che personalizzate, possono essere diverse ogni volta
le domande possono essere in lingue diverse attraverso l'uso di Impostazioni locali
puoi dire cosa era predefinito o personalizzato tramite QuestionTypeId nelle Domande

Sono disponibili più tabelle per l'infrastruttura di fornitura delle domande predefinite e l'inserimento di domande personalizzate.

Inoltre, la mia testa stava barcollando con domande / sovraccarico di questionari. Qualche denominazione migliore aiuterebbe a rendere le cose più leggibili.

score 0 · Answer 2

Vorrei andare per l'opzione 1., ma penso che non ci sia alcun motivo per:

a json string which defines the custom fields.

Alcuni database (ad esempio PostgreSQL) hanno il supporto per attraversare JSON, quindi per ottenere l'elenco delle chiavi da un JSON che fai:

select key from json_each('{"a":"foo", "b":"bar"}');

Quindi nel tuo esempio puoi semplicemente selezionare quel JSON dalla tabella delle risposte (tramite ID risposta) e usare json_each per generare un elenco di domande. In questo modo non avrai dati duplicati nel tuo database.

Inoltre, lo memorizzerei come tipo jsonb (supportato da alcuni DB, ad esempio PostgreSQL).