Come progetteresti un database utente con campi personalizzati

Questa domanda riguarda come dovrei progettare un database, può essere un database relazionale / nosql, a seconda di quale sarà la soluzione migliore

Dato un requisito in cui è necessario creare un sistema che coinvolgerà un database per tracciare "Azienda" e "Utente". Un singolo utente appartiene sempre a una sola azienda

• Un utente può appartenere a una sola società
• Una società può avere molti utenti

Il design per il tavolo "Azienda" è piuttosto semplice. La società avrà i seguenti attributi / colonne: (manteniamolo semplice)

ID, COMPANY_NAME, CREATED_ON

Primo scenario

Semplice e diretto, gli utenti hanno tutti lo stesso attributo, quindi questo può essere facilmente fatto in stile relazionale, tabella utente:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

Secondo scenario

Cosa succede se diverse aziende vogliono memorizzare attributi di profilo diversi per i loro utenti. Ogni azienda avrà un set definito di attributi che si applicherebbe a tutti gli utenti di quella società.

Per esempio:

• La società A vuole archiviare: LIKE_MOVIE (booleano), LIKE_MUSIC (booleano)
• La società B vuole archiviare: FAV_CUISINE (String)
• La società C vuole archiviare: OWN_DOG (booleano), DOG_COUNT (int)

Approccio 1

il modo della forza bruta è avere un singolo schema per l'utente e lasciare che abbiano valori nulli quando non appartengono alla società:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON

Il che è un po 'brutto perché finirai con un sacco di NULLS e righe utente che hanno colonne che sono irrilevanti per loro (cioè tutti gli utenti appartenenti alla Società A hanno valori NULL per FAV_CUISINE, OWN_DOG, DOG_COUNT)

Approccio 2

un secondo approccio, è avere "campo in forma libera":

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON

Che sarebbe brutto da solo poiché non hai idea di quali campi personalizzati siano, il tipo di dati non rifletterà i valori memorizzati (ad esempio, memorizzeremo il valore int come VARCHAR).

Approccio 3

Ho esaminato il campo JSON di PostgreSQL, nel qual caso avrai:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_PROFILE_JSON, CREATED_ON

In questo caso, come saresti in grado di applicare diversi schemi a un utente? Un utente con la società A avrà uno schema simile

 {"LIKE_MOVIE":"boolean", "LIKE_MUSIC": "boolean"}

Mentre un utente con la società C avrà uno schema diverso:

 {"OWN_DOG ":"boolean", "DOG_COUNT": "int"}

Come devo risolvere questo problema? Come posso progettare correttamente il database per consentire questo schema flessibile per un singolo "oggetto" (Utente) basato sulla relazione che hanno (Azienda)?

soluzione relazionale? soluzione nosql?

Modifica: ho anche pensato a una tabella "CUSTOM_PROFILE" che essenzialmente memorizzerà gli attributi dell'utente nelle righe anziché nelle colonne.

Ci sono 2 problemi con questo approccio:

1) I dati crescono per utente crescono come righe anziché come colonne - e questo significa che per ottenere un quadro completo dell'utente, è necessario eseguire molti join, più join alla tabella "profilo personalizzato" sui diversi attributi personalizzati

2) Il valore dei dati viene sempre archiviato come VARCHAR come generico, anche se sappiamo che i dati dovrebbero essere interi o booleani, ecc.

Si prega di considerare questo come un'alternativa. I due esempi precedenti richiederanno entrambi di apportare modifiche allo schema man mano che l'ambito dell'applicazione aumenta, inoltre la soluzione "colonna_personalizzata" è difficile da estendere e mantenere. Alla fine ti ritroverai con Custom_510 e poi immagina quanto terribile sarà questa tabella con cui lavorare.

Per prima cosa usiamo il tuo schema Aziende.

[Companies] ComnpanyId, COMPANY_NAME, CREATED_ON

Successivamente utilizzeremo anche il tuo schema Utenti per gli attributi richiesti di livello superiore che verranno utilizzati / condivisi da tutte le società.

[Users] UserId, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON

Successivamente creiamo una tabella in cui definiremo i nostri attributi dinamici che sono specifici degli attributi utente personalizzati di ciascuna azienda. Quindi qui un valore di esempio della colonna Attribute sarebbe "LikeMusic":

[UserAttributeDefinition] UserAttributeDefinitionId, CompanyId, Attribute

Successivamente definiamo una tabella UserAttributes che conterrà i valori degli attributi utente

[UserAttributes] UserAttributeDefinitionId, UserId, Value

Questo può essere modificato in molti modi per migliorare le prestazioni. È possibile utilizzare più tabelle per UserAttributes, ognuna delle quali specifica il tipo di dati archiviato in Value o lasciarlo semplicemente come VarChar e lavorare con esso come archivio di valori chiave.

È inoltre possibile spostare CompanyId dalla tabella UserAttributeDefiniton e in una tabella di riferimenti incrociati per prove future.

Utilizzare un database NoSQL. Ci sarebbero documenti dell'azienda e dell'utente. Gli utenti avrebbero creato parte del loro schema in modo dinamico basato su un modello utente (testo per indicare campi / tipi per quella società.

\Company\<uniqueidentifier>
    - Name: <Name>
    - CreatedOn: <datetime>
    - UserTemplate: <Text>

\User\<uniqueidentifier>
    - COMPANY_ID: <ID>
    - FIRST_NAME: <Text>
    - LAST_NAME: <Text>
    - EMAIL: <Text>
    - CREATED_ON: <datetime>
    - * Dynamically created fields per company

Ecco come potrebbe apparire in qualcosa come Firebase.com Dovresti imparare come farlo in qualunque cosa tu scelga.

Se ti imbatterai spesso in richieste di campo personalizzate, in realtà lo modellerei in modo abbastanza simile al database. Creare una tabella che contiene i metadati relativi a ciascun campo personalizzato, CompanyCustomField (a chi appartiene, il tipo di dati, ecc.) E un'altra tabella CompanyCustomFieldValues ​​che contiene CustomerId, FieldId e il valore. Se stai usando qualcosa come Microsoft Sql Server, la colonna del valore dovrebbe essere un tipo di dati sql_variant.

Naturalmente questo non è facile poiché avrai bisogno di un'interfaccia che consenta agli amministratori di definire campi personalizzati per ciascun cliente e un'altra interfaccia che utilizza effettivamente questi metadati per creare un'interfaccia utente per raccogliere i valori dei campi. E se hai altri requisiti, come il raggruppamento di campi insieme o la necessità di fare un tipo di campo dell'elenco di selezione, devi accontentarlo con più metadati / altre tabelle (ad esempio, CompanyCustomFieldPickListOptions).

Questo non è banale, ma ha il vantaggio di non richiedere modifiche al database / modifiche al codice per ogni nuovo campo personalizzato. Sarà necessario codificare anche qualsiasi altra funzionalità dei campi personalizzati (ad esempio, se si desidera regex convalidare un valore di stringa o consentire solo date tra determinati intervalli o se è necessario abilitare un campo personalizzato basato su un altro valore di campo personalizzato ).

Un'alternativa alle altre risposte è quella di avere una tabella chiamata profile_attrib, o simile che lo schema sia completamente gestito dalla tua applicazione.

Man mano che vengono aggiunti attributi personalizzati ALTER TABLE profile_attrib ADD COLUMN like_movie TINYINT(1), è possibile vietare l'eliminazione. Ciò ridurrebbe al minimo il tuo join, garantendo comunque flessibilità.

Immagino che il piccolo compromesso sia che l'applicazione ora ha bisogno di alterare i privilegi di tabella per il database e devi essere intelligente nel sanificare i nomi delle colonne.

La tua domanda ha molte potenziali soluzioni. Una soluzione è archiviare gli attributi aggiuntivi come XML. L'XML può essere archiviato come testo o se si utilizza un database che supporta i tipi XML come XML (SQL Server). La memorizzazione come testo limita la tua capacità di interrogazione (come la ricerca su un attributo personalizzato), ma se la memorizzazione e il recupero sono tutto ciò di cui hai bisogno, allora è una buona soluzione. Se è necessario eseguire una query, l'archiviazione dell'XML come tipo XML sarebbe un'opzione migliore (sebbene sia più specifica del fornitore).

Ciò darà la possibilità di memorizzare un numero qualsiasi di attributi per un cliente con l'aggiunta di una colonna di aggiunta nella tabella dei clienti. Si potrebbero archiviare gli attributi come hashset o dizionario, si perderà la sicurezza dei tipi poiché tutto sarà una stringa con cui iniziare, ma se si applica una stringa di formato standard per date, numeri, valori booleani, funzionerà OK.

Per maggiori informazioni:

https://msdn.microsoft.com/en-us/library/hh403385.aspx

Anche la risposta di WalterMitty è valida, anche se se si hanno molti clienti con attributi diversi si potrebbe finire con molte tabelle se si segue il modello di ereditarietà. Dipende da quanti attributi personalizzati sono condivisi tra i clienti.

È necessario normalizzare il database in modo da disporre di 3 tabelle diverse per ogni diverso tipo di profilo aziendale. Usando il tuo esempio, avresti tabelle con colonne:

USER_ID, LIKE_MOVIE, LIKE_MUSIC

USER_ID, FAVORITE_CUISINE

USER_ID, OWN_DOG, DOG_COUNT

Questo approccio presuppone che conoscerai prima la forma delle informazioni che un'azienda desidera archiviare e che non cambierà spesso. Se la forma dei dati è sconosciuta in fase di progettazione, probabilmente sarebbe meglio andare con quel campo JSON o un database nosql.

Per una ragione o per l'altra, i database sono il campo in cui si manifesta più spesso l'effetto piattaforma interna. Questo è solo un altro caso del pop-up anti-pattern.

In questo caso, stai cercando di combattere la soluzione naturale e corretta. Gli utenti dell'azienda A non sono utenti dell'azienda B e dovrebbero avere le proprie tabelle per i propri campi.

Il fornitore del database non ti addebita in base alla tabella e non hai bisogno del doppio dello spazio su disco per il doppio delle tabelle (in effetti, avere due tabelle è più efficiente perché non memorizzi gli attributi di A per gli utenti di B. Anche archiviando solo NULL occupa spazio).

Naturalmente, se ci sono sufficienti campi comuni, è possibile fattorizzarli in una tabella Users condivisa e disporre di una chiave esterna in ciascuna delle tabelle utente specifiche dell'azienda. Questa è una struttura così semplice che nessun ottimizzatore di query di database si trova in difficoltà. Qualsiasi JOIN necessario è banale.

La mia soluzione presuppone che si chiamerebbe questa query da un programma e si dovrebbe essere in grado di eseguire l'elaborazione post. Puoi avere le seguenti colonne:

ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_VALUES

CUSTOM_VALUES sarà del tipo stringa che memorizza la coppia chiave e valori. la chiave sarà il nome della colonna e il valore sarà il valore della colonna, ad es

LIKE_MOVIE;yes;LIKE_MUSIC;no;FAV_CUISINE;rice

in questo CUSTOM_VALUES salverai solo le informazioni esistenti. Quando si esegue una query dal programma, è possibile dividere questa stringa e utilizzarla.

Ho usato questa logica e funziona benissimo, è solo che dovrai applicare la logica di filtraggio nel codice e non nelle query.