Iniziamo con i "prodotti" come esempio rappresentativo: i database OLAP che coinvolgono prodotti sono in genere utilizzati per creare query come
-
quali sono i 10 prodotti più venduti negli ultimi 3 mesi?
-
quali 10 prodotti ci hanno apportato il maggior profitto nell'ultimo anno?
-
in quali località abbiamo avuto la maggior carenza nella consegna di determinati prodotti?
Tutte queste query dovrebbero visualizzare i nomi di prodotti all'utente / analista. Quegli utenti certamente non possono occuparsi direttamente di cose come ID prodotto o codici hash.
Un'altra cosa importante dei cubi OLAP è che vengono in genere creati da un'istantanea congelata di un database OLTP, il che significa che i nomi dei prodotti non cambiano durante la vita del set di dati OLAP. Pertanto, in genere non è necessario mantenere i nomi dei prodotti in un luogo centrale e mantenerli in modo normalizzato. Quando i nomi dei prodotti cambiano in mezzo nel database OLTP, il cubo OLAP li otterrà la prossima volta che viene eseguita una nuova istantanea, il che significa che l'intero set di dati viene ricostruito da zero.
Quindi la progettazione più semplice di una tabella OLAP per casi di utilizzo tipici sarà spesso quella di utilizzare direttamente i nomi degli oggetti come chiavi. Introducendo un'altra tabella Product con un ID prodotto e la referenza che l'ID è un progetto più complesso che probabilmente non porterà a miglioramenti della velocità oa query più semplici.
Codificare i nomi nel modo in cui hai suggerito di usare un dizionario in memoria può essere visto come un'ottimizzazione, sia ottimizzando lo spazio (che è spesso economico oggi), magari ottimizzando la velocità (che è spesso mal giudicata perché le persone dimenticano di misurare) .
Ma come ogni ottimizzazione, ha un costo: il sistema diventa più complicato, perché, se le stringhe vengono prima codificate, le query utili richiederanno un ulteriore passaggio di decodifica per presentare i risultati in un formato che gli utenti possano gestire.
Inoltre, spesso questo genere di ottimizzazioni non vale la pena, perché
-
semplicemente non è richiesta alcuna ottimizzazione (perché il design semplice è abbastanza veloce così com'è, per i requisiti specificati)
-
dopo l'implementazione e la misurazione, risultano non restituire risparmi significativi (o peggiorare le cose)
-
la tecnologia del database sottostante fa già queste ottimizzazioni "sotto la cappa" (come la deduplicazione delle stringhe)
Quindi suggerisco di iniziare a pensare alle stringhe di codifica come ID a 16 bit
-
quando hai un reale problema di prestazioni o archiviazione da risolvere
-
quando puoi fare un'ipotesi (o meglio - alcune misurazioni) che la duplicazione di quelle stringhe è la causa principale del problema e che la deduplicazione può essere di aiuto.
Non ottimizzare "nel caso" o perché "senti" qualcosa potrebbe essere meno costoso, quelle sensazioni tendono a fuorviare le persone.