Come progettare un database relazionale in cui gli utenti possono creare campi personalizzati

Question

Come progettare un database relazionale in cui gli utenti possono creare campi personalizzati

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

2

Ho cercato un modo per progettare un database per grandi quantità di lead (utenti) con campi personalizzati.

Ive controlla questo ( Come sarebbe si progetta un database utente con campi personalizzati ), ma questa soluzione limiterebbe la quantità di campi personalizzati.

Finora l'ho progettato su tre tavoli:

leads                    (ID, phone, email)
leads_fields             (ID, name, type, required)
leads_fields_content     (ID, fields_id, lead_id, content)

Gli utenti possono creare tutto il leads_fields di cui hanno bisogno, fx. 20 campi.

Quindi, quando avrò un lead, andrei su e check in leads_fields_content per lead_id , ottenere quella raccolta e ottenere il corrispondente leads_fields a cui si fa riferimento.

Vedo che funziona - Tuttavia, un cliente desidera caricare 300.000 lead dal primo giorno. Quindi sono 300.000 righe in leads . Quindi diciamo che ci sono 20 campi per ogni lead. Ciò creerebbe quindi 300.000 * 20 righe in leads_fields_content che corrisponde a 6.000.000 di righe. Questo è solo per un cliente.

La mia domanda : è questo il modo corretto di progettarlo, tenendo conto della quantità di tempo necessaria per passare a 300.000 righe, e successivamente a 6.000.000? E questo sarebbe solo esponenzialmente più grande.

database-design relational-database

posta Patrick 11.10.2018 - 14:21

fonte

2 risposte

0

Non esiste davvero un modo per avere campi personalizzati in un database relazionale pur rimanendo relazionali. Un database NoSQL può essere un'opzione migliore per soddisfare le tue esigenze. Se deve essere memorizzato in un database relazionale, memorizzo tutti i campi personalizzati in una colonna JSON / XML e solo colonne per campi utili per la ricerca o abbastanza comuni da essere presenti sulla maggior parte / tutti i record (ad esempio, e-mail, telefono, nome). In questo modo si mantiene abbastanza ragionevole il tasso di crescita del proprio database in quanto non è necessario archiviare i probabili milioni di null per ogni campo personalizzato su ciascun record. Idealmente potresti avere una "ricerca di base" che non guarda nella colonna del campo personalizzato, e una "ricerca avanzata" che è molto più lenta che guarda i campi personalizzati. Sarebbe anche utile avere una tabella che mantenga il nome e i tipi di campi personalizzati che un record potrebbe dover almeno tentare di ridurre il numero di campi che sono fondamentalmente le stesse informazioni espresse in modo leggermente diverso.

Avrai anche bisogno di avere tabelle o database separati per ogni cliente. Mentre questo aiuta a limitare la dimensione dei tavoli, ci sono altri motivi più importanti per farlo. Il Cliente 1 non sarà felice di non poter aggiornare i propri lead perché il client 2 sta inserendo 300k lead. Anche il client 2 sarà molto sconvolto se il client 1 aggiorna, legge o elimina uno dei loro lead a causa di un bug o del client 1 compromesso. Se il client 1 aumenta significativamente il proprio database, è possibile spostare più facilmente un database su un server separato per mantenere le prestazioni per tutti i client, piuttosto che ridimensionare un database su più server.

risposta data 11.10.2018 - 15:15

fonte

Leggi altre domande sui tag database-design relational-database

Devo spostare le attività che sono solo per un elemento specifico solo per ciclo chiuso? Qual è esattamente il termine "modello" definito nel contesto dello sviluppo basato sul dominio?

score 5 · Accepted Answer

Se i tuoi clienti vogliono essere completamente liberi di definire i propri campi personalizzati, il tuo approccio in generale va bene. Tuttavia, per i numeri indicati, è necessario prendere alcune precauzioni per mantenere il sistema performante e scalabile.

Suppongo che quando ci sono 300.000 lead con 20 campi, c'è un'alta probabilità di avere molte di queste voci di contenuto vuote per i campi non obbligatori. Nel design suggerito, puoi semplicemente lasciare fuori quei record dalla tabella leads_fields_content , senza bisogno di creare un record con un contenuto vuoto per quelli. Quindi, se c'è solo una piccola percentuale dei campi pieni di contenuti, ottieni solo quella piccola percentuale di record in leads_fields_content , non necessariamente 6 milioni. Il tuo design consente già di memorizzare tabelle sparse in modo efficiente!
L'indicizzazione corretta dovrebbe essere obbligatoria. Tuttavia, questo è molto più semplice per i campi che sono noti in fase di progettazione. Quindi, se si conoscono alcuni campi standard che sono normalmente richiesti per qualsiasi cliente e non è necessario essere personalizzabili (come il nome di un lead), sarebbe probabilmente una buona idea renderlo una parte fissa della tabella lead. Quindi puoi creare un indice specifico per quei campi.
Se ciascuno dei tuoi clienti ha il suo "schema personalizzato", è chiaro che desidera che i suoi dati siano separati al 100% da altri clienti. Ad esempio, non avrai mai requisiti per la ricerca sul contenuto di diversi clienti. Quindi sarà probabilmente meglio separare fisicamente i dati di ciascun cliente. Il modo in cui ciò avviene dipende dal DBMS che si sta utilizzando: tabelle separate per cliente, tabelle in schemi diversi, tablespace diversi, stessa tabella in diversi database "logici" su un server o istanze di database completamente diverse per cliente, forse su macchine diverse - Dipende tutto dal tipo di sistema DB che stai utilizzando, quanti clienti hai e quanto è scalabile il tuo sistema.