MS SQL Server
  1. MS SQL Server
  3. Data Vault 2.0 dans SQL Server
Intereting Posts
Comment convertir (MontNom, année) en format DateTime Phrase "WHEN" conditionnelle dans SQL Server Dans SQL Server requête ralentit considérablement lorsque variable dans la clause SELECT login auto-récursive SQL avec le regroupement Les techniques de matérialisation T-SQL CTE ne fonctionnent pas sur SQL Server 2012 Performances SQL Server: colonnes Index + INCLUDE non clusterisées par rapport à l'index clusterisé – équivalent? Comment montrer la collection de toutes les valeurs d'une colonne dans SQL Server 2014 SUM conditionnelle dans SQL Server 2014 database en état de restauration la famille de supports sur le périphérique est incorrecte. SQL Server ne peut pas traiter cette famille de médias Comment puis-je requestr quel count Active Directory est associé à un user SQL Server? Est-il possible d'avoir deux unités de persistance MSSQL dans une transaction sans XA? Cas de Sum Colum () après le pivot Fonction HashBytes SQL Server PARTITION PAR Nom, Identifiant pour comparer et détecter les problèmes

Data Vault 2.0 dans SQL Server

Dans Data Vault 2.0, on hache la key métier et prend ce hachage comme key primaire de la table. Les tables de liens utilisent également la key primaire de hachage pour créer une relation.

Mon problème concerne les hashs qui sont essentiellement randoms, l'optimizre de requête ne peut pas appliquer de bonne estimation car les statistics – bien sûr – ne sont pas utilisables pour datatables réparties randoms.

Ainsi, l'optimiseur de requêtes utilise des plans bizarres où il veut sortinger souvent (car il pense qu'il n'y a que 4 lignes à sortinger). Puisque je ne suis sûrement pas le premier à traiter le coffre de données dans le server sql, comment est-ce que c'est réparable?

Lorsque l'optimiseur de requêtes utilise une search d'index ou un opérateur de jointure, il manque complètement l'estimation de ligne et choisit des plans ridicules.

Je dois leur confier des astuces de jointure et des conseils de requête tels que (FORCE ORDER) pour en tirer quelque chose.

Quelle est l'approche commune pour cela?

Je suis tout à fait d'accord avec votre conclusion que le hachage rendra toutes datatables ayant une structure / ordre totalement random, ce qui rendra impossible toute forme de statistics de database utiles.

J'ai fait quelques expériences sur le server SQL moi-même et suis arrivé à la même conclusion que vous, soutenu par les plans Explain

C'est pourquoi je crois fermement que vous / nous devrions envisager d'utiliser la key de gestion concaténée comme une key primaire au lieu de le hacher.

Les arguments qui sont donnés pour le hachage sont dans le domaine de:

  1. Rejoindre Char (32) (la string de caractères d'un hachage MD5) est plus performant que la jonction sur des champs de caractères variables
  2. Le hachage réduit les zones sensibles dans votre cluster MPP lors de l' écriture de données

Mais je n'ai pas encore vu de preuve pour l'argument 1: comme vous le mentionnez, vous perdez toutes les statistics utiles lors de l'adhésion! De plus: beaucoup de keys d'affaires naturelles que je connais sont en réalité beaucoup plus petites que 32 caractères … J'ai en fait posé une question liée à ce sujet il y a quelques jours …

Puis à l'argument 2: Dans la plupart des bases de données MPP NoSQL (valeur-key, document, famille de colonnes), il est conseillé d'utiliser une bonne key NATURELLE (concaténée) comme key de partition, pas un hachage. Exemple: voir ce conseil pour Cassandra.

C'est pourquoi je ne suis pas d'accord avec la théorie de Hashing de Data Vault 2: Je n'ai vu aucune preuve le supportant … C'est une des raisons pour lesquelles je propose une nouvelle approche de modélisation d'set @ DMZone Berlin en octobre.

Personnellement, je ne voudrais pas hacher le BK mais inclurais tous les champs du HUB si c'était une key composée. Pourquoi la table LINK utiliserait les valeurs de hachage, elle devrait utiliser le HUB_ID que je définirais toujours comme une valeur incrémentée

Je créerais et stockerais cependant un HASH dans la table SAT comme ceci est le moyen le plus rapide de vérifier les changements dans le process ETL: Hash les valeurs entrant et comparez au hachage sur l'logging SAT actuel – aucun point en recalculant le hash sur l'logging existant.