SQL: per alcuni attributi specifici degli utenti di diversi client, come gestire lo schema?

Question

SQL: per alcuni attributi specifici degli utenti di diversi client, come gestire lo schema?

#1 da (1 voti)
#2 da (-3 voti)

1

Ho clienti, ognuno dei quali ha un'app con un gruppo di utenti.

I loro dati utente potrebbero essere abbastanza diversi, ma c'è anche una grande sovrapposizione. Es: tutti i loro utenti hanno "genere" ed "età" e molte altre cose, quindi ha senso avere uno schema user_table standard su tutti i client (con una colonna per ogni attributo).

Ma ci sono anche informazioni utente specifiche per ogni cliente. Ex. uno potrebbe avere "relationship_status" per i propri utenti, che altri client non hanno. Mentre un altro ha "altezza" per i propri utenti, quali altri client non hanno.

Come faccio a progettare uno schema appropriato per entrambi questi casi contemporaneamente?

Una possibilità è di avere in qualche modo uno schema diverso per ogni cliente, ma sembra che potrebbe essere una seccatura inutile. Un'altra possibilità è quella di inserire tutte le colonne nello schema standard su tutti i client, ma le colonne che sono univoche per un singolo cliente resterebbero vuote per tutti gli altri client.

sql coding-standards schema postgres

posta tscizzle 27.03.2015 - 22:07

fonte

2 risposte

Leggi altre domande sui tag sql coding-standards schema postgres

Best practice nella denominazione delle risorse Android [closed] Generazione di elementi di presentazione con Javascript vs PHP

score 1 · Answer 1

Dipende se devi o meno fare qualcosa di "interessante" con quel dato aggiuntivo, specifico per il cliente.

In pratica, è improbabile che qualsiasi elaborazione avvenga su campi personalizzati, dal momento che dovresti fornire quell'elaborazione tu stesso, con una sorta di infrastruttura di plugin o fornire build personalizzate per ogni cliente, un accordo che può diventare rapidamente ingombrante .

Se non è richiesta alcuna logica di elaborazione aggiuntiva e i campi personalizzati possono essere forniti al client in un formato tabulare (diversamente da un formato colonnare), è possibile utilizzare un progetto Entity-Attribute-Value per fornire funzionalità di campo personalizzate. Ciò consente al client di aggiungere personalmente le definizioni dei campi.

Ulteriori letture
Entity-Attribute -Valore del modello

score -3 · Answer 2

Secondo la mia onesta opinione avere diversi gruppi di tabelle per diversi gruppi di utenti aggiungerà complessità al tuo codice avendo una quantità "X" di query SQL. Perché per uno schema avrai una stringa di Query SQL per l'acquisizione dei dati da lì, ma per un altro schema avrai un'altra stringa di Query SQL che acquisirà i dati da lì.

Inoltre, penso che sia più difficile da mantenere.

Se si suppone che questo schema sia uno schema / tabella generale contenente dati utente, trovo più semplice avere uno solo schema e per le colonne che non si applicano a un utente specifico, basta inserire un testo N / A predefinito.

Questo può fornire una tabella di database con più N / A in esso di quanto tu non voglia. Ma penso che sia un trade off ne vale la pena assicurandosi di avere solo un set di query SQL per un solo schema.