Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur Historisation de données sur Sql Server 2005

Historisation de données sur Sql Server 2005

7 réponses
Avatar
Oriane
Bonjour,

quelle est la solution "standard" pour stocker dans Sql Server différents
états d'une même instance de table ?

Je m'explique: une table stocke par exemple l'état d'une voiture, avec un
champ propriétaire. Ce champ, ainsi que d'autres, est mis à jour à chaque
vente du véhicule. Peut-on utilser des métadonnées des colonnes pour garder
trace et pouvoir récupérer ces données et savoir par exemple quel était le
propriétaire à une date précise ? Ou faut-il ajouter une autre table ou
d'autres champs (un champ de type date) afin de créer plusieurs instances de
cette même table qui chacune corresponde à l'état du véhicule durant une
tranche de temps ?

Je suppose que ce problème est général et que tout plein de solutions
existent...

Oriane
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Fred BROUARD
Oriane a écrit :
Bonjour,

quelle est la solution "standard" pour stocker dans Sql Server
différents états d'une même instance de table ?



Il n'existe aucune solution standard, pour des raisons similaires à
celles évoquées dans le post précédent...


Je m'explique: une table stocke par exemple l'état d'une voiture, avec
un champ propriétaire. Ce champ, ainsi que d'autres, est mis à jour à
chaque vente du véhicule. Peut-on utilser des métadonnées des colonnes
pour garder trace et pouvoir récupérer ces données et savoir par exemple
quel était le propriétaire à une date précise ? Ou faut-il ajouter une
autre table ou d'autres champs (un champ de type date) afin de créer
plusieurs instances de cette même table qui chacune corresponde à l'état
du véhicule durant une tranche de temps ?



C'est à vous de décidez ce que vous voulez historiser et mettre en
oeuvre la modèle adéquat :
table avec version de ligne ou tables redondantes ou supertable avec
état transitoires....


Je suppose que ce problème est général et que tout plein de solutions
existent...



Oui, à vous de les concevoir !


Oriane



A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Oriane
"Fred BROUARD" a écrit dans le message de
news:

C'est à vous de décidez ce que vous voulez historiser et mettre en oeuvre
la modèle adéquat :
table avec version de ligne ou tables redondantes ou supertable avec état
transitoires....


Euh, c'est quoi les super-tables et les tables avec version de ligne ?


Je suppose que ce problème est général et que tout plein de solutions
existent...



Oui, à vous de les concevoir !


Oui mais la réutilisation est par essence plus sûre. Aussi il doit y avoir
des "design patterns" pour ce genre de pb...
Bon je vais creuser !!!
Avatar
Fred BROUARD
Oriane a écrit :

"Fred BROUARD" a écrit dans le message de
news:

C'est à vous de décidez ce que vous voulez historiser et mettre en
oeuvre la modèle adéquat :
table avec version de ligne ou tables redondantes ou supertable avec
état transitoires....


Euh, c'est quoi les super-tables et les tables avec version de ligne ?


Je suppose que ce problème est général et que tout plein de solutions
existent...



Oui, à vous de les concevoir !


Oui mais la réutilisation est par essence plus sûre. Aussi il doit y
avoir des "design patterns" pour ce genre de pb...



j'n rigole d'avance !!!! Vous confondez conception objet et bases de
données relationnelles... Les SGBDR ne sont pas du tout objet et très
loin de ce monde là...
Ceci explique vos questions...
Je vous invite à prendre quelques cours sur ce qu'est un SGBDR et revoir
entièrement vos positions...

Exemple de cours, celui du CNAM (Arts & Métiers)

A +

Bon je vais creuser !!!





--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Oriane
"Fred BROUARD" a écrit dans le message de
news:%
Oriane a écrit :

"Fred BROUARD" a écrit dans le message de
news:

C'est à vous de décidez ce que vous voulez historiser et mettre en
oeuvre la modèle adéquat :
table avec version de ligne ou tables redondantes ou supertable avec
état transitoires....


Euh, c'est quoi les super-tables et les tables avec version de ligne ?




J'aurais aimé que vous répondiez à la question !!


Je suppose que ce problème est général et que tout plein de solutions
existent...



Oui, à vous de les concevoir !


Oui mais la réutilisation est par essence plus sûre. Aussi il doit y
avoir des "design patterns" pour ce genre de pb...



j'n rigole d'avance !!!! Vous confondez conception objet et bases de
données relationnelles... Les SGBDR ne sont pas du tout objet et très loin
de ce monde là...
Ceci explique vos questions...


Je ne vois pas le rapport entre design patterns et conception objet. Par
contre je vois très bien le rapport entre UML et SGBDR, ce qiu a fait par
ailleurs le sujet de bouquin.

J'ai pris la précaution de mettre le terme "design pattern" entre
parenthèses, car je veux simplement dire par là qu'il peut y avoir des
"morceaux" de schémas de base de données standard pour ce genre de chose.
Mais apparemment non.

Oriane
Avatar
Fred BROUARD
Oriane a écrit :

"Fred BROUARD" a écrit dans le message de
news:%
Oriane a écrit :

"Fred BROUARD" a écrit dans le message de
news:

C'est à vous de décidez ce que vous voulez historiser et mettre en
oeuvre la modèle adéquat :
table avec version de ligne ou tables redondantes ou supertable avec
état transitoires....


Euh, c'est quoi les super-tables et les tables avec version de ligne ?




J'aurais aimé que vous répondiez à la question !!


Je suppose que ce problème est général et que tout plein de
solutions existent...



Oui, à vous de les concevoir !


Oui mais la réutilisation est par essence plus sûre. Aussi il doit y
avoir des "design patterns" pour ce genre de pb...



j'n rigole d'avance !!!! Vous confondez conception objet et bases de
données relationnelles... Les SGBDR ne sont pas du tout objet et très
loin de ce monde là...
Ceci explique vos questions...


Je ne vois pas le rapport entre design patterns et conception objet. Par
contre je vois très bien le rapport entre UML et SGBDR, ce qiu a fait
par ailleurs le sujet de bouquin.



Mais contrairement à ce que vous semblez penser UML n'est pas destiné à
la modélisation des données relationnelle.
Il est vrai que UML permet une représentation des modèles de données de
SGBDR, mais cela reste de la modélisation entité association et non de
la modélisation objet. Il n'y a donc pas de "transposition" possible
entre la notation ER et le "pur" UML.
Il se trouve que Christian Soutou, qui a écrit de UML à SQL est co
auteur du dernier livre sur SQL que nous avons écrit ensemble!


J'ai pris la précaution de mettre le terme "design pattern" entre
parenthèses, car je veux simplement dire par là qu'il peut y avoir des
"morceaux" de schémas de base de données standard pour ce genre de
chose. Mais apparemment non.



Je crois que vous commencez à comprendre la différence entre l'objet et
le relationnel.
je pense que vous avez encore beaucoup de chemin à faire !


Oriane



A +

--

Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Avatar
Oriane
"Fred BROUARD" a écrit dans le message de
news:edD8$
Mais contrairement à ce que vous semblez penser UML n'est pas destiné à la
modélisation des données relationnelle.


Il ne me semble pas avoir écrit cela.


Je crois que vous commencez à comprendre la différence entre l'objet et le
relationnel.


Attention, votre charité vous égare !
Avatar
Fred BROUARD
Oriane a écrit :
"Fred BROUARD" a écrit dans le message de
news:edD8$
Mais contrairement à ce que vous semblez penser UML n'est pas destiné
à la modélisation des données relationnelle.


Il ne me semble pas avoir écrit cela.


Je crois que vous commencez à comprendre la différence entre l'objet
et le relationnel.


Attention, votre charité vous égare !



je ne fais jamais la charité... Mais il m'arrive de tenter d'aider les
autres... Vanité ou illussion ?





A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************