In che modo questo contesto può essere modellato (adempiendo alle forme normali)?

Question

In che modo questo contesto può essere modellato (adempiendo alle forme normali)?

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

2

Sono un principiante in DB. Ho studiato alcuni esempi di base, ma ora sto studiando casi più complessi che coinvolgono molte tabelle correlate tra loro. Sto studiando come modellare un DB per un sistema per conferenze, ma c'è un dettaglio che sembra difficile da modellare.

Il dettaglio è che una conferenza può avere più tipi di registrazione e ogni tipo di registrazione può avere campi definiti dall'utente, ad esempio,

l'organizzatore della conferenza può creare una conferenza con un tipo di registrazione "Generale" che richiede i campi "nome, email" che devono essere compilati dall'utente che effettua la registrazione per ogni partecipante che sta registrando.
può creare un altro tipo di registrazione "vip" con i campi "nome, email, telefono" che devono essere compilati dall'utente che effettua la registrazione per ogni partecipante che si sta registrando.

Sai come aggiungere questo contesto al diagramma (adempiendo ai moduli normali)?

Diagramma (senza quella parte fileds definita dall'utente)

database database-design

posta Denn 20.12.2017 - 21:05

fonte

2 risposte

Leggi altre domande sui tag database database-design

Come può essere misurata e quantificata la riusabilità del codice Python? Come apparirebbe un URI di risorsa in REST, che viola il principio di non modificare il suo significato semantico?

score 1 · Answer 1

Vado sempre con l'approccio a più tabelle

registration
    id (for gods sake don't use an int)
    type
    name
    email

registration_vip
    id (same value as corresponding registration row)
    phone

//get all the vip registrations with extra fields
select * 
    from 
        registration r
    left join 
        registration_vip v
        on v.id = r.id
    where
        r.type ='vip'

Ovviamente, se hai diversi tipi e vuoi ottenere il tutto, devi fare più di una query. RESIST L'URGE PER SCRIVERE SQL SQL DINAMICO

Tuttavia, puoi eseguirli tutti in un'unica chiamata e restituire più set di dati, se necessario, quindi non c'è davvero alcun impatto sulle prestazioni.

Preferisco di gran lunga questo rispetto all'approccio alternativo "molte colonne null". Principalmente a causa della mancanza di null, ma anche della facilità di aggiungere nuovi tipi senza influenzare le tabelle esistenti.

score 1 · Answer 2

La risposta alternativa per "Organizzatore può creare campi personalizzati in fase di esecuzione"

Se consenti all'utente di creare campi personalizzati hai tre soluzioni ugualmente cattive

Aggiungi x (ad esempio 10) campi varchar (max) customField1, customField2 ... ecc. alla tua tabella per memorizzare i dati. Avere una tabella separata con i nomi definiti dall'utente di questi campi per tipo di registrazione

Questo è il più semplice ma il più limitato. Hai un numero massimo di campi personalizzati che puoi memorizzare senza cambiare la tabella e segnalarli è un incubo.

aggiungi tabelle aggiuntive:

come

questions
    id
    registrationTypeId
    text ('what is your favourite colour?')

answers
    id
    questionId
    answer

Questo è meglio in quanto puoi avere tutti i campi che vuoi. La segnalazione è leggermente più facile da poter ruotare sulla domanda id e roba.

Tuttavia diventa più complicato quando si desidera aggiungere la convalida e diversi tipi di numero di risposta, data, menu a discesa ecc.

Utilizza un tipo di documento e memorizzalo in un unico campo come xml o json

Impossibile segnalare contro, ma il più flessibile in termini di convalida e presentazione. Ad esempio, è possibile memorizzare un intero modulo html.