Progettazione del database, come gestire i freelance

Non c'è niente di sbagliato nel fornire un'organizzazione individuale per ciascun libero professionista, anche quando c'è un solo "dipendente" in questa organizzazione. In realtà, questo riflette la situazione legale molto meglio, dal momento che un libero professionista può avere il ruolo di una società (proprio indirizzo / account di posta / numero di telefono) e il ruolo completamente separato di una persona privata o persona impiegata pure. E ti aiuterà a modellare anche altre cose più uniformi.

Il CRM che stiamo utilizzando nella nostra azienda funziona esattamente come questo

• per prima cosa crei una nuova organizzazione / azienda nel sistema, con indirizzo, indirizzo di posta centrale, sito web, telefono ecc.

• le persone di contatto vengono sempre aggiunte all'organizzazione "attiva". È possibile inserire un indirizzo diverso dall'indirizzo dell'azienda, se lo si desidera (ma non è necessario). E non puoi aggiungere contatti senza un'organizzazione.

• le persone di contatto non cambiano la loro azienda; possono diventare inattivi, e puoi aggiungere una nuova persona di contatto che sia una copia di una esistente. Questo aiuta a gestire le informazioni storiche che in passato erano i miei interlocutori (anche quando si trovano in una nuova azienda oggi) ed evita problemi come i tuoi.

L'ultimo punto non è sicuramente la soluzione migliore per ogni sistema. Devi decidere di questo tipo di modello adatto alle tue esigenze nel tuo caso specifico.

Per la tua modifica: nel caso in cui desideri veramente che le organizzazioni e le singole persone siano responsabili, potrebbe essere meglio seguire le idee di Fowler dal suo libro "Modelli di analisi" su come modellare la responsabilità (vedi pagina 4) . Crea un "party" di tavolo aggiuntivo per persone e organizzazioni. Ogni entità in "partito" ha una voce corrispondente in "organizzazione" o una in "persona". Quando si esegue la modellazione relazionale agli oggetti, la "festa" sarebbe solo la classe base della persona e dell'organizzazione. La fattura ottiene solo un "ID partito" come chiave esterna di riferimento.

Ciò consentirà di trattare le singole persone e le organizzazioni in modo uniforme.

A prima vista, direi che due cose renderebbero le cose più semplici:

Crea un'organizzazione che rappresenti "Freelance" e assegna tutti i contatti freelance a tale organizzazione.

e

Una fattura deve contenere sia un ID dell'organizzazione che un ContactId, che rappresenta la relazione Organizzazione e Contatto al momento della fattura.

Se il contatto cambia le organizzazioni in un secondo momento, non importa, perché la fattura ha ancora l'ID organizzazione originale.

Un avvertimento da parte di un designer esperto che ama i database: cercare di indovinare le relazioni dati senza disporre di un set approvato di casi di utilizzo aziendali, diagrammi di relazioni tra entità, un diagramma di flusso dati principale all'interno dell'azienda, ecc. è pericoloso. La tua domanda sembra mostrare che stai cercando di catturare i difetti di relazione "al volo" dal punto di vista del database, invece di pianificare la struttura dai diagrammi di dati approvati e quindi di costruire i ponti che potresti dover incuneare nel vecchio sistema il nuovo. Ciò può portare a problemi di contabilità ... non solo incubi di dati come quelli che hai già ipotizzato. ( un esempio di caso )

Una tendenza interessante che ho visto con alcuni sistemi è quella di far rintracciare le persone come oggetti dati, che possono essere convalidati come oggetti del mondo reale da informazioni di identificazione personale. Le persone possono avere un portafoglio che include ruoli e storie, consentendo loro di essere referenziati mentre si spostano attraverso le organizzazioni o tag che consentono loro di fare riferimento a vari servizi di dati o data warehouse. Fai attenzione ai dubbi sulla privacy ...

Il cliente come ruolo che può alternare l'utilizzo dei dati dagli oggetti Organizzazione o Person, con un indicatore a bandiera, può consentire di gestire il problema di integrazione di b2c b2b senza richiedere troppe modifiche di transizione. In generale, le transazioni memorizzano i dettagli come la chiave esterna di un oggetto nella posizione di un ruolo e di un timestamp. Ad esempio un oggetto chiamato Location, connesso a GIS, potrebbe avere un ruolo come ship-from, ship-to, bill-to, bill-from o mail-to.

Le tabelle per i sistemi critici dovrebbero avere: ID univoco, flag attivo / inattivo, data-ora attiva, data e ora dell'ultima modifica, data-ora non attiva, codice di stato - Questi permetteranno il miglior controllo su query di dati e transazioni storici registri di controllo. Il codice di stato ti consente di tenere traccia di cose come la fusione di record, l'inserimento di errori, le bandiere legali, ecc., Nonché la riduzione della duplicazione dei dati nelle transazioni

I sistemi ERP più recenti gestiranno database strutturati e dati non strutturati, SQL e NoSQL, ecc. Oggetti, ruoli e transazioni come mentalità utilizzati nella pianificazione possono ridurre al minimo il tuo mal di testa in futuro.