database / orm design del modello per i contatti

Question

database / orm design del modello per i contatti

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

-2

Sto costruendo un crm interno che ha contatti che sono solo persone con nome, cognome, email, telefono, ecc. I contatti possono essere uno o più tipi e.t.c. candidati di lavoro, responsabili delle assunzioni, clienti, lavoratori, subappaltatori ecc ... e in base ai tipi ci sono più campi specifici campi.

Sto costruendo il software in laravel usando eloquent orm e il mio primo pensiero è di avere una tabella / oggetto dei contatti che memorizza i campi comuni e poi una ha-una per gli altri tipi, ognuno contenente i campi specifici per quei tipi . Altrimenti posso solo memorizzare tutti i campi come nullable nella tabella di un contatto è is_candidate, is_worker ecc.

Qualche raccomandazione su un approccio che ha funzionato bene per il tuo caso d'uso?

database data-structures database-design relational-database data

posta the-a-train 26.10.2018 - 15:02

fonte

2 risposte

0

Se stai partendo da zero vorrei dare un'occhiata a un DB oggetto / documento (nosql) invece che a un relazionale. Ciò ti consentirà di avere variabilità di campi / attributi sulle entità.

Tuttavia, per le relazioni sono entrambi approcci corretti. Se ciò che hai descritto non cambia mai, sarebbe più opportuno avere campi null / vuoti sul tavolo stesso. Mentre se questa realtà cambia, puoi trovarti a dover sputare quei campi in nuove tabelle correlate.

Quindi il mio consiglio è pianificare attentamente con tutta la conoscenza che hai che non potresti presentare qui, ma essere pronto a cambiare.

risposta data 26.10.2018 - 16:03

fonte

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

Che cos'è un'astrazione software? [duplicare] Posso dire che l'interfaccia è un insieme di comportamenti generali? [duplicare]

score 0 · Accepted Answer

Sono un fan di un modello in cui il tuo contatto ha un campo tipo e un ID, in cui tutti gli aspetti specifici si trovano in altre tabelle. Mi piace di più perché a un certo punto ti verrà chiesto "Ehi, puoi aggiungere una funzione per cambiare contatto x in contatto y?". Con il modello menzionato, tutto ciò che fai è cambiare il valore nel campo del tipo.

Un altro vantaggio è che un contatto può avere tutte le informazioni ad esso collegate tramite l'ID. Se un contatto è un richiedente e si trasforma in un dipendente, non devi fare nulla, ma compilare le informazioni del dipendente. Neanche le informazioni sul candidato devono essere cancellate. Il contatto può quindi diventare più tipi contemporaneamente, potreste persino sbarazzarvi del campo tipo e dedurlo da quali dati esso ha o non ha.

Puoi anche creare interfacce utente molto flessibili con questo modello.

Modifica: se ci pensate, qualsiasi campo come "is_worker" è sempre ridondante. Sai se è un lavoratore se sono presenti i dati del lavoratore. Questa dovrebbe essere una proprietà nell'applicazione anziché un campo di database.