Dovremmo usare le chiavi primarie surrogate per ogni tabella? [duplicare]

-2

Stiamo sviluppando un modello di dati per un database di marketing che importerà file di transazioni, clienti, inventario, ecc. e la direttiva è UN processo che funziona per ogni cliente. Ci è stato detto che ogni client avrà diversi layout di importazione e diverse colonne che identificano la chiave primaria di una tabella.

La nostra idea iniziale è di ottenere definizioni dal client su quali colonne rendono un record univoco, archiviarle in una tabella di mappatura e quindi avere tabelle di ricerca che traducono automaticamente quelle chiavi primarie in chiavi sostitutive interne per ogni tabella di destinazione in modo che ogni tabella è conforme a una chiave primaria intera, indipendentemente dal numero di colonne / tipi utilizzati per creare il vero pk.

Il primo problema principale che ho visto è stato quando / se è necessario eseguire il mapping delle tabelle di ricerca per ottenere dati che non sono stati archiviati nel modello dati principale, ma ho la certezza che tutto ciò che vogliamo venga sottoposto a query verrà duplicato nella ricerca e nelle tabelle principali in modo che non dovrebbe essere un problema.

Questo tipo di flessibilità sembra causare gravi limitazioni su:

  1. Stack di tecnologia (nessun modo per mappare dinamicamente questi file di importazione SSIS, hanno bisogno di molto SQL dinamico o java / c #)

  2. Scalabilità (basata su preoccupazioni precedenti e test iniziali, questo sarebbe difficile scalare senza problemi di velocità)

  3. Complessità (stiamo già eseguendo alcune modifiche complesse al codice quando proviamo a implementare tutte queste tabelle con cambiamenti storici logging mantenendo l'associazione alle tabelle di ricerca, ad esempio)

La mia domanda: è fattibile o esiste un'altra soluzione ovvia che ci manca?

    
posta jimdrang 25.03.2014 - 02:41
fonte

1 risposta

3

We have been told every client will have different import layouts and different columns that identify a table's primary key.

Gentile signore del cielo, NON lascia che questo entri in produzione senza stabilire un processo standard chiaro per assegnare ad ogni record di importanza un singolo tasto effettivo a livello di sistema . Una chiave dello stesso formato per tutti i clienti, in cui è possibile restituire le importazioni con la chiave di sistema aggiunta, se necessario.

Le colonne specificate dall'utente per l'univocità richiedono solo problemi di dati, a meno che i tuoi clienti non siano tecnologicamente avanzati e, se sono tecnologicamente avanzati, possono creare il proprio db. I tavoli "mappa" di Mammoth sono solo un mal di testa che aspetta di accadere; cosa succede quando alla fine il tuo cliente ha due clienti "John M Smith", che hanno entrambi lo stesso numero di telefono e indirizzo perché un nonno si è trasferito con il nipote che gli ha dato il nome?

Per quanto riguarda "cosa fare con i campi non aggiunti al nostro set di dati principale", questo è il supporto XML per i database. (O JSON, o una EAV tabella.) XML è meglio di JSON a questo proposito, poiché la maggior parte dei tipi di database con un tipo di dati "XML" esplicito ha anche il modo di indicizzare e suddividere il contenuto XML. (supponendo che tu non abbia un database che parla JSON, cioè.)

    
risposta data 25.03.2014 - 03:25
fonte