Réflexion : Colonne calculé de cheksum [Résolu]

Jinroh77 · 22/02/2011, 16h04

Bonjour à tous,
J'arrive chez un client qui alimente une base décisionnelle.
Dans les tables de dim, je trouve dans quelques unes une colonne qui a pour valeur par défaut un calcul de cheksum sur les autres colonnes de la table.

Ok ça permet d'identifier de manière unique une ligne de données, mais ça me parait très lourd pour chaque insert ???

7gyY9w1ZY6ySRgPeaefZ · 22/02/2011, 16h32

Quelle est ta question?
Ça semble être un dispositif pour valider qu'un ligne n'a pas été modifiée.

Jinroh77 · 22/02/2011, 16h41

Ma question : je suis d'accord avec le besoin : identifier une ligne de manière unique. Mais les moyens mis en place par ce calcul du checksum me parait particulièrement lourd.
Le checksum est calculé à l'insertion où uniquement au select ?

7gyY9w1ZY6ySRgPeaefZ · 22/02/2011, 16h55

Citation:

Envoyé par Jinroh77

Le checksum est calculé à l'insertion où uniquement au select ?

Bonne question.
Regarde s'il y a un trigger ou si c'est une colonne calculée.

Jinroh77 · 22/02/2011, 16h58

C'est bien une formule, non persistante.
Ca veut donc dire qu'il n'y a aucun surplus tant que la colonne n'est pas sélectionnée ?

mikedavem · 22/02/2011, 21h21

En général les colonnes CHECKSUM permettent de remplacer les colonnes de taille importante dans des contraintes d'unicités ou index pour des raisons de performance.

Le checksum est uniquement calculé à l'insertion des données dans votre cas.

++

SQLpro · 22/02/2011, 22h48

et il n'est pas forcément unique car les risques de télescopage sont important.

A +

mikedavem · 23/02/2011, 07h25

Tu as raison SQLPro, effectivement, la solution de l'unicité est limitée ici car CHECKSUM ne délivre qu'un entier (4 octets).

++

Jinroh77 · 23/02/2011, 10h02

Etant dans le cadre d'une base décisionnelle, la colonne calculée checksum est présente dans la source, dans l'entrepôt de données et on fait une comparaison dessus.

Si cette colonne checksum est calculée à l'insertion, que le calcul d'un checksum est lourd, cela veut dire qu'ils perdent beaucoup de temps au chargement.

mikedavem · 24/02/2011, 21h58

Si la comparaison s'effectue avant insertion des données (ce qui est logique) pourquoi recalculer à la volée un CHECKSUM dans les tables de dimension ?

++

Jinroh77 · 25/02/2011, 10h02

Ils effectuent les alimentations par procédures stockées.
Ils font donc une jointure entre la valeur de checksum qu'ils viennent de calculer dans leur base de staging et celle dans l'entrepôt.

22/02/2011, 16h04	#1
Jinroh77 Modérateur Alexandre Chemla Consultant en Business Intelligence Inscription : février 2006 Messages : 1 771 Détails du profil Informations personnelles : Nom : Alexandre Chemla Âge : 28 Localisation : France, Seine et Marne (Île de France) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : février 2006 Messages : 1 771 Points : 1 834 Points : 1 834	Réflexion : Colonne calculé de cheksum Bonjour à tous, J'arrive chez un client qui alimente une base décisionnelle. Dans les tables de dim, je trouve dans quelques unes une colonne qui a pour valeur par défaut un calcul de cheksum sur les autres colonnes de la table. Ok ça permet d'identifier de manière unique une ligne de données, mais ça me parait très lourd pour chaque insert ???
	00

22/02/2011, 16h32	#2
7gyY9w1ZY6ySRgPeaefZ Expert Confirmé dba Inscription : juillet 2007 Messages : 2 520 Détails du profil Informations personnelles : Sexe : Localisation : Canada Informations professionnelles : Activité : dba Informations forums : Inscription : juillet 2007 Messages : 2 520 Points : 3 967 Points : 3 967	Quelle est ta question? Ça semble être un dispositif pour valider qu'un ligne n'a pas été modifiée. __________________ les règles du forum - mode d'emploi du forum Aucun navigateur ne propose d'extension boule-de-cristal : postez votre code et vos messages d'erreurs. (Rappel : "ça ne marche pas" n'est pas un message d'erreur) JE NE RÉPONDS PAS aux questions techniques par message privé. Écrire en français sur un forum est une marque minimale de respect.
	00

22/02/2011, 16h41	#3
Jinroh77 Modérateur Alexandre Chemla Consultant en Business Intelligence Inscription : février 2006 Messages : 1 771 Détails du profil Informations personnelles : Nom : Alexandre Chemla Âge : 28 Localisation : France, Seine et Marne (Île de France) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : février 2006 Messages : 1 771 Points : 1 834 Points : 1 834	Ma question : je suis d'accord avec le besoin : identifier une ligne de manière unique. Mais les moyens mis en place par ce calcul du checksum me parait particulièrement lourd. Le checksum est calculé à l'insertion où uniquement au select ?
	00

22/02/2011, 16h58	#5
Jinroh77 Modérateur Alexandre Chemla Consultant en Business Intelligence Inscription : février 2006 Messages : 1 771 Détails du profil Informations personnelles : Nom : Alexandre Chemla Âge : 28 Localisation : France, Seine et Marne (Île de France) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : février 2006 Messages : 1 771 Points : 1 834 Points : 1 834	C'est bien une formule, non persistante. Ca veut donc dire qu'il n'y a aucun surplus tant que la colonne n'est pas sélectionnée ?
	00

22/02/2011, 21h21	#6
mikedavem Responsable SQL Server David BARBARIN Expert SQL Server Inscription : août 2005 Messages : 3 723 Détails du profil Informations personnelles : Nom : David BARBARIN Localisation : France, Haute Savoie (Rhône Alpes) Informations professionnelles : Activité : Expert SQL Server Secteur : Conseil Informations forums : Inscription : août 2005 Messages : 3 723 Points : 6 844 Points : 6 844	En général les colonnes CHECKSUM permettent de remplacer les colonnes de taille importante dans des contraintes d'unicités ou index pour des raisons de performance. Le checksum est uniquement calculé à l'insertion des données dans votre cas. ++ __________________ Blog \| Articles SQL Server \| TSQL Challenges \| English blog
	00

22/02/2011, 22h48	#7
SQLpro Rédacteur/Modérateur Frédéric BROUARD Expert SGBDR & SQL Inscription : mai 2002 Messages : 10 950 Détails du profil Informations personnelles : Nom : Frédéric BROUARD Localisation : France Informations professionnelles : Activité : Expert SGBDR & SQL Secteur : Conseil Informations forums : Inscription : mai 2002 Messages : 10 950 Points : 17 769 Points : 17 769	et il n'est pas forcément unique car les risques de télescopage sont important. A + __________________ Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ *Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.* Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
	00

23/02/2011, 07h25	#8
mikedavem Responsable SQL Server David BARBARIN Expert SQL Server Inscription : août 2005 Messages : 3 723 Détails du profil Informations personnelles : Nom : David BARBARIN Localisation : France, Haute Savoie (Rhône Alpes) Informations professionnelles : Activité : Expert SQL Server Secteur : Conseil Informations forums : Inscription : août 2005 Messages : 3 723 Points : 6 844 Points : 6 844	Tu as raison SQLPro, effectivement, la solution de l'unicité est limitée ici car CHECKSUM ne délivre qu'un entier (4 octets). ++ __________________ Blog \| Articles SQL Server \| TSQL Challenges \| English blog
	00

23/02/2011, 10h02	#9
Jinroh77 Modérateur Alexandre Chemla Consultant en Business Intelligence Inscription : février 2006 Messages : 1 771 Détails du profil Informations personnelles : Nom : Alexandre Chemla Âge : 28 Localisation : France, Seine et Marne (Île de France) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : février 2006 Messages : 1 771 Points : 1 834 Points : 1 834	Etant dans le cadre d'une base décisionnelle, la colonne calculée checksum est présente dans la source, dans l'entrepôt de données et on fait une comparaison dessus. Si cette colonne checksum est calculée à l'insertion, que le calcul d'un checksum est lourd, cela veut dire qu'ils perdent beaucoup de temps au chargement.
	00

24/02/2011, 21h58	#10
mikedavem Responsable SQL Server David BARBARIN Expert SQL Server Inscription : août 2005 Messages : 3 723 Détails du profil Informations personnelles : Nom : David BARBARIN Localisation : France, Haute Savoie (Rhône Alpes) Informations professionnelles : Activité : Expert SQL Server Secteur : Conseil Informations forums : Inscription : août 2005 Messages : 3 723 Points : 6 844 Points : 6 844	Si la comparaison s'effectue avant insertion des données (ce qui est logique) pourquoi recalculer à la volée un CHECKSUM dans les tables de dimension ? ++ __________________ Blog \| Articles SQL Server \| TSQL Challenges \| English blog
	00

25/02/2011, 10h02	#11
Jinroh77 Modérateur Alexandre Chemla Consultant en Business Intelligence Inscription : février 2006 Messages : 1 771 Détails du profil Informations personnelles : Nom : Alexandre Chemla Âge : 28 Localisation : France, Seine et Marne (Île de France) Informations professionnelles : Activité : Consultant en Business Intelligence Informations forums : Inscription : février 2006 Messages : 1 771 Points : 1 834 Points : 1 834	Ils effectuent les alimentations par procédures stockées. Ils font donc une jointure entre la valeur de checksum qu'ils viennent de calculer dans leur base de staging et celle dans l'entrepôt.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email