Discussion :

[Kropernic]

Bonjour,

Après avoir lu un article du blog de sqlpro, je me pose une question sur l'atomicité (je me rends compte en l'écrivant que ce n'est p-e pas le bon terme).

Voici le lien de l'article : http://blog.developpez.com/sqlpro/p1...ances-petites/

Et voici ma question (que vous pourrez trouvez en commentaire de l'article mais que je poste ici pour toucher un public plus large) :

Dans le cadre d'une base de donnée servant à gérer les privilèges d'accès des utilisateurs à certaines applications propre à l'entreprise, il existerait la table suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE DBO.tbl_UM_Demand_UMD(
   ID INT IDENTITY(1,1) NOT NULL,
   USER_ID INT NOT NULL,
   APP_ID INT NOT NULL,
   RIGHT_ID INT NOT NULL,
   ASK_DATE DATETIME NOT NULL CONSTRAINT DF_tbl_UM_Demande_UMD_ASK_DATE DAFAULT (getdate()),
   VALIDATED BIT NOT NULL CONSTRAINT DF_tbl_UM_Demande_UMD_VALIDATED DAFAULT ('false'),
   VALIDATION_DATE DATETIME NULL
)

Dans cette table, les colonnes USER_ID, APP_ID et RIGHT_ID sont bien sûr des clefs étrangères vers les tables adéquates.

Ma question porte sur les colonnes VALIDATED et VALIDATION_DATE.
À partir du moment où une date de validation est présente, on peut en déduire à 100% que la demande est bien validée. De ce fait, la colonne VALIDATED est-elle nécessaire ? Est-ce une "grave" faute de conception ou cela peut-il être envisagé dans certains cas ?

Griftou.

[Arkhena]

Bonjour,

Pour répondre à cette question, il serait mieux de connaître l'usage de la base.
S'agit-il d 'une base décisionnelle, transactionnelle ou les deux?

Cordialement,

Arkhena

[Kropernic]

Euh... En français ça donne quoi ta question ?

Je ne suis DBA que par la force des choses. J'ai bien reçu une formation à sql serveur 2005 fin de l'année dernière mais bon... DBA, c'est tout un métier et ce n'est pas avec une formation que je vais combler mes lacunes...

Du coup, même si je sais ce que les termes décision et transaction signifient (et encore, pour décision, dans le cadre d'une DB, je ne suis pas sûr), je ne comprends pas le sens de ta question

[Arkhena]

Bonjour,

On appelle communément "base transactionnelle" une base de données qui reçoit beaucoup de requêtes d'insertion et/ou de modification.
On appelle "base décisionnelle" une base qui après un gros chargement de données gère beaucoup de requêtes de lecture.

Ma question en française est donc comment est utilisée cette base en général et le champ validated de cette table en particulier ?

Si vous ne savez pas, vous pouvez utiliser SQL Profiler pour essayer de savoir.

Cordialement,

Arkhena

[Kropernic]

C'est une table sur laquelle vont être faite pas mal de requête de type INSERT (toutes les demandes d'accès aux applications en fait).

Et pour chaque ligne, au moins une requête UPDATE sera faite (pour dire si on valide la demande où si on la rejette (j'ai oublié la colonne DEL de type BIT dans ma description))

Et bien sûr, elle fera également l'objet de requête de type SELECT qui devraient être en nombre assez important.

VALIDATED sera mis à vrai si la demande est validée et DEL restera à NULL.
Si la demande est rejetée, VALIDATED restera à NULL et DEL sera mis à vrai.

[StringBuilder]

Je pense que "VALIDATED" ne peut pas découler de "VALIDATION_DATE".
=> En effet, si aujourd'hui, tu passes "VALIDATED" à 1, tu vas allimenter "VALIDATION_DATE".
Mais si tu décides de pouvoir révoquer la validation, quelle sera la règle ? Vider "VALIDATION_DATE", et ainsi perdre la date de la première validation ?
Allimenter "VALIDATION_DATE" et ainsi connaitre la date de révocation ?

Selon la règle, on ne pourra peut-être plus déduire "VALIDATED" aussi facilement.
En revanche, si il est possible de valider/invalider plusieurs fois le droit, ou gérer par exemple des plages d'accès, alors je mettrais une seconde table avec "date début validité / date fin validité". Ou bien "validation_status" / "validation_status_date".
=> Et comme ça, tu ne te pose plus de question

En tout cas, je trouve dangereux de se dire "je peux déduire ça de ce truc donc je le stock pas" quand il ne s'agit pas d'un simple comptage. En effet, les règles tacites ne sont pas forcément évidentes pour tous, et surtout, demain le modèle peut évoluer, et un telle modélisation risque de mettre en péril la reprise des données (car on fini toujours pas tomber sur un cas pas prévu, et on sait pas quoi faire de la donnée)