Rollback "manuel"/compensation sur Sql server 2005
4 réponses
Oriane
Bonjour,
je soumets une problématique qui n'est pas propre à Sql Server, mais c'est
la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une transaction,
puis éventuellement, après les avoir "commitées", les défaire et revenir en
arrière. Ces modifs mettent à jour des champs, des tables avec naturellement
des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux
solutions consistant à restaurer la bases à une date antérieure aux
changement car c'est un peu "lourd" et plutôt destiné à récupérer un état
antérieur après un plantage. Mais peut-on générer les commandes inverses de
celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un
rollback) et les lancer pour annuler cette transaction précise ?
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
Fred BROUARD
Oriane a écrit :
Bonjour,
je soumets une problématique qui n'est pas propre à Sql Server, mais c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une transaction, puis éventuellement, après les avoir "commitées", les défaire et revenir en arrière. Ces modifs mettent à jour des champs, des tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux solutions consistant à restaurer la bases à une date antérieure aux changement car c'est un peu "lourd" et plutôt destiné à récupérer un état antérieur après un plantage. Mais peut-on générer les commandes inverses de celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est impossible à cause simplement du paradox temporel. Soit la transaction est validée, soit elle est annulée. Une fois validée on ne peut décider de revenir en arrière pour l'annuler car d'autres opérations ont pu être faites depuis. Imaginez simplement un compta dans laquelle on alimente une table avec le CA de la journée à minuit... Que se passe t-il si une transaction à 18h est annulée le lendemain ???
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes raisons, car le base sera fatalement incohérente.
Visiblement vous avez une problème de conception fonctionnelle !
A +
Si vous avez des idées...
Oriane
-- 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 ***********************
Oriane a écrit :
Bonjour,
je soumets une problématique qui n'est pas propre à Sql Server, mais
c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une
transaction, puis éventuellement, après les avoir "commitées", les
défaire et revenir en arrière. Ces modifs mettent à jour des champs, des
tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux
solutions consistant à restaurer la bases à une date antérieure aux
changement car c'est un peu "lourd" et plutôt destiné à récupérer un
état antérieur après un plantage. Mais peut-on générer les commandes
inverses de celles que l'on a fait (c'est-à-dire faire ce que fait Sql
lors d'un rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est
impossible à cause simplement du paradox temporel. Soit la transaction
est validée, soit elle est annulée. Une fois validée on ne peut décider
de revenir en arrière pour l'annuler car d'autres opérations ont pu être
faites depuis.
Imaginez simplement un compta dans laquelle on alimente une table avec
le CA de la journée à minuit... Que se passe t-il si une transaction à
18h est annulée le lendemain ???
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes
raisons, car le base sera fatalement incohérente.
Visiblement vous avez une problème de conception fonctionnelle !
A +
Si vous avez des idées...
Oriane
--
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 ***********************
je soumets une problématique qui n'est pas propre à Sql Server, mais c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une transaction, puis éventuellement, après les avoir "commitées", les défaire et revenir en arrière. Ces modifs mettent à jour des champs, des tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux solutions consistant à restaurer la bases à une date antérieure aux changement car c'est un peu "lourd" et plutôt destiné à récupérer un état antérieur après un plantage. Mais peut-on générer les commandes inverses de celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est impossible à cause simplement du paradox temporel. Soit la transaction est validée, soit elle est annulée. Une fois validée on ne peut décider de revenir en arrière pour l'annuler car d'autres opérations ont pu être faites depuis. Imaginez simplement un compta dans laquelle on alimente une table avec le CA de la journée à minuit... Que se passe t-il si une transaction à 18h est annulée le lendemain ???
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes raisons, car le base sera fatalement incohérente.
Visiblement vous avez une problème de conception fonctionnelle !
A +
Si vous avez des idées...
Oriane
-- 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 ***********************
Oriane
"Fred BROUARD" a écrit dans le message de news:%
Oriane a écrit :
Bonjour,
je soumets une problématique qui n'est pas propre à Sql Server, mais c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une transaction, puis éventuellement, après les avoir "commitées", les défaire et revenir en arrière. Ces modifs mettent à jour des champs, des tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux solutions consistant à restaurer la bases à une date antérieure aux changement car c'est un peu "lourd" et plutôt destiné à récupérer un état antérieur après un plantage. Mais peut-on générer les commandes inverses de celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est impossible à cause simplement du paradox temporel. Soit la transaction est validée, soit elle est annulée. Une fois validée on ne peut décider de revenir en arrière pour l'annuler car d'autres opérations ont pu être faites depuis.
Je ne suis pas d'accord. Et d'ailleurs ce que je veux faire porte un nom, on appelle ca une compensation. Il est évident qu'il faut prendre des précautions et garder la notion "d'isolation" dans la transaction. Je veux dire par là que les données impactées par le changement ne doivent pas être modifées une deuxième fois.
Imaginez simplement un compta dans laquelle on alimente une table avec le CA de la journée à minuit... Que se passe t-il si une transaction à 18h est annulée le lendemain ???
Oui c'est vrai. Mais voir la remarque précédente.
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes raisons, car le base sera fatalement incohérente.
Sauf si l'isoltaion est garantie.
Visiblement vous avez une problème de conception fonctionnelle !
Non mais il est vrai que ce que je dois faire c'est non pas de modifier des tables mais de créer des instances, de les relier à un objet "travail", puis en partant de cet objet travail, d'effacer toutes les nouvelles instances créées si besoin. Parce que garantir l'isolation, hum j'ai des doutes...dans l'opérationnel...
A +
Merci de votre aide
Oriane
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
news:%23XQH8JtoHHA.4400@TK2MSFTNGP03.phx.gbl...
Oriane a écrit :
Bonjour,
je soumets une problématique qui n'est pas propre à Sql Server, mais
c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une
transaction, puis éventuellement, après les avoir "commitées", les
défaire et revenir en arrière. Ces modifs mettent à jour des champs, des
tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux
solutions consistant à restaurer la bases à une date antérieure aux
changement car c'est un peu "lourd" et plutôt destiné à récupérer un état
antérieur après un plantage. Mais peut-on générer les commandes inverses
de celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un
rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est
impossible à cause simplement du paradox temporel. Soit la transaction est
validée, soit elle est annulée. Une fois validée on ne peut décider de
revenir en arrière pour l'annuler car d'autres opérations ont pu être
faites depuis.
Je ne suis pas d'accord. Et d'ailleurs ce que je veux faire porte un nom, on
appelle ca une compensation. Il est évident qu'il faut prendre des
précautions et garder la notion "d'isolation" dans la transaction. Je veux
dire par là que les données impactées par le changement ne doivent pas être
modifées une deuxième fois.
Imaginez simplement un compta dans laquelle on alimente une table avec le
CA de la journée à minuit... Que se passe t-il si une transaction à 18h
est annulée le lendemain ???
Oui c'est vrai. Mais voir la remarque précédente.
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes
raisons, car le base sera fatalement incohérente.
Sauf si l'isoltaion est garantie.
Visiblement vous avez une problème de conception fonctionnelle !
Non mais il est vrai que ce que je dois faire c'est non pas de modifier des
tables mais de créer des instances, de les relier à un objet "travail", puis
en partant de cet objet travail, d'effacer toutes les nouvelles instances
créées si besoin. Parce que garantir l'isolation, hum j'ai des doutes...dans
l'opérationnel...
je soumets une problématique qui n'est pas propre à Sql Server, mais c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une transaction, puis éventuellement, après les avoir "commitées", les défaire et revenir en arrière. Ces modifs mettent à jour des champs, des tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux solutions consistant à restaurer la bases à une date antérieure aux changement car c'est un peu "lourd" et plutôt destiné à récupérer un état antérieur après un plantage. Mais peut-on générer les commandes inverses de celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est impossible à cause simplement du paradox temporel. Soit la transaction est validée, soit elle est annulée. Une fois validée on ne peut décider de revenir en arrière pour l'annuler car d'autres opérations ont pu être faites depuis.
Je ne suis pas d'accord. Et d'ailleurs ce que je veux faire porte un nom, on appelle ca une compensation. Il est évident qu'il faut prendre des précautions et garder la notion "d'isolation" dans la transaction. Je veux dire par là que les données impactées par le changement ne doivent pas être modifées une deuxième fois.
Imaginez simplement un compta dans laquelle on alimente une table avec le CA de la journée à minuit... Que se passe t-il si une transaction à 18h est annulée le lendemain ???
Oui c'est vrai. Mais voir la remarque précédente.
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes raisons, car le base sera fatalement incohérente.
Sauf si l'isoltaion est garantie.
Visiblement vous avez une problème de conception fonctionnelle !
Non mais il est vrai que ce que je dois faire c'est non pas de modifier des tables mais de créer des instances, de les relier à un objet "travail", puis en partant de cet objet travail, d'effacer toutes les nouvelles instances créées si besoin. Parce que garantir l'isolation, hum j'ai des doutes...dans l'opérationnel...
A +
Merci de votre aide
Oriane
Fred BROUARD
Oriane a écrit :
"Fred BROUARD" a écrit dans le message de news:%
Oriane a écrit :
Bonjour,
je soumets une problématique qui n'est pas propre à Sql Server, mais c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une transaction, puis éventuellement, après les avoir "commitées", les défaire et revenir en arrière. Ces modifs mettent à jour des champs, des tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux solutions consistant à restaurer la bases à une date antérieure aux changement car c'est un peu "lourd" et plutôt destiné à récupérer un état antérieur après un plantage. Mais peut-on générer les commandes inverses de celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est impossible à cause simplement du paradox temporel. Soit la transaction est validée, soit elle est annulée. Une fois validée on ne peut décider de revenir en arrière pour l'annuler car d'autres opérations ont pu être faites depuis.
Je ne suis pas d'accord. Et d'ailleurs ce que je veux faire porte un nom, on appelle ca une compensation. Il est évident qu'il faut prendre des précautions et garder la notion "d'isolation" dans la transaction. Je veux dire par là que les données impactées par le changement ne doivent pas être modifées une deuxième fois.
Dans ce cas, pas de trigger, pas de clefs autouincrémentées, pas de transactions dans un niveau d'isolation inférieure au niveau serializable, ce qui veut dire : bonjour les performances et bonjour l'usine à gaz !!!
Imaginez simplement un compta dans laquelle on alimente une table avec le CA de la journée à minuit... Que se passe t-il si une transaction à 18h est annulée le lendemain ???
Oui c'est vrai. Mais voir la remarque précédente.
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes raisons, car le base sera fatalement incohérente.
Sauf si l'isoltaion est garantie.
Visiblement vous avez une problème de conception fonctionnelle !
Non mais il est vrai que ce que je dois faire c'est non pas de modifier des tables mais de créer des instances, de les relier à un objet "travail", puis en partant de cet objet travail, d'effacer toutes les nouvelles instances créées si besoin. Parce que garantir l'isolation, hum j'ai des doutes...dans l'opérationnel...
Prenez un bon cours sur les SGBDR cela fait maintenant 27 ans que cela marche et très bien. Des centaines de milliard de transactions sont faites tous les jours dans tous les SGBDR de la planète et cela sans aucun défaut d'isolation, sauf l'erreur de codage du développeur !
Votre éclatant manque de culture vous fait poser des questions qui n'ont aucun sens et ont été résolé dans les années 70/80 par les chercheurs comme Codd, Date, Stonebraker pour ne citer qu'eux ! Et ces solutions sont aujourd'hui en oeuvre dans les SGBDR comme oracle, SQL Server ou IBM DB2 depuis 2 décénnies...
A +
A +
Merci de votre aide
Oriane
-- 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 ***********************
Oriane a écrit :
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
news:%23XQH8JtoHHA.4400@TK2MSFTNGP03.phx.gbl...
Oriane a écrit :
Bonjour,
je soumets une problématique qui n'est pas propre à Sql Server, mais
c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une
transaction, puis éventuellement, après les avoir "commitées", les
défaire et revenir en arrière. Ces modifs mettent à jour des champs,
des tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas
aux solutions consistant à restaurer la bases à une date antérieure
aux changement car c'est un peu "lourd" et plutôt destiné à récupérer
un état antérieur après un plantage. Mais peut-on générer les
commandes inverses de celles que l'on a fait (c'est-à-dire faire ce
que fait Sql lors d'un rollback) et les lancer pour annuler cette
transaction précise ?
par nature, essence et conception ce que vous demandez de faire est
impossible à cause simplement du paradox temporel. Soit la transaction
est validée, soit elle est annulée. Une fois validée on ne peut
décider de revenir en arrière pour l'annuler car d'autres opérations
ont pu être faites depuis.
Je ne suis pas d'accord. Et d'ailleurs ce que je veux faire porte un
nom, on appelle ca une compensation. Il est évident qu'il faut prendre
des précautions et garder la notion "d'isolation" dans la transaction.
Je veux dire par là que les données impactées par le changement ne
doivent pas être modifées une deuxième fois.
Dans ce cas, pas de trigger, pas de clefs autouincrémentées, pas de
transactions dans un niveau d'isolation inférieure au niveau
serializable, ce qui veut dire : bonjour les performances et bonjour
l'usine à gaz !!!
Imaginez simplement un compta dans laquelle on alimente une table avec
le CA de la journée à minuit... Que se passe t-il si une transaction à
18h est annulée le lendemain ???
Oui c'est vrai. Mais voir la remarque précédente.
Il n'existe pas non plus d'outils tiers pour ce faire et pour les
mêmes raisons, car le base sera fatalement incohérente.
Sauf si l'isoltaion est garantie.
Visiblement vous avez une problème de conception fonctionnelle !
Non mais il est vrai que ce que je dois faire c'est non pas de modifier
des tables mais de créer des instances, de les relier à un objet
"travail", puis en partant de cet objet travail, d'effacer toutes les
nouvelles instances créées si besoin. Parce que garantir l'isolation,
hum j'ai des doutes...dans l'opérationnel...
Prenez un bon cours sur les SGBDR cela fait maintenant 27 ans que cela
marche et très bien. Des centaines de milliard de transactions sont
faites tous les jours dans tous les SGBDR de la planète et cela sans
aucun défaut d'isolation, sauf l'erreur de codage du développeur !
Votre éclatant manque de culture vous fait poser des questions qui n'ont
aucun sens et ont été résolé dans les années 70/80 par les chercheurs
comme Codd, Date, Stonebraker pour ne citer qu'eux !
Et ces solutions sont aujourd'hui en oeuvre dans les SGBDR comme oracle,
SQL Server ou IBM DB2 depuis 2 décénnies...
A +
A +
Merci de votre aide
Oriane
--
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 ***********************
je soumets une problématique qui n'est pas propre à Sql Server, mais c'est la base dont je me sers.
Il s'agit de pouvoir effectuer des modifs sur une base sur une transaction, puis éventuellement, après les avoir "commitées", les défaire et revenir en arrière. Ces modifs mettent à jour des champs, des tables avec naturellement des ordees Sql update/create.
Y a-t-il des solutions propres à Sql Server 2005 ? Je ne pense pas aux solutions consistant à restaurer la bases à une date antérieure aux changement car c'est un peu "lourd" et plutôt destiné à récupérer un état antérieur après un plantage. Mais peut-on générer les commandes inverses de celles que l'on a fait (c'est-à-dire faire ce que fait Sql lors d'un rollback) et les lancer pour annuler cette transaction précise ?
par nature, essence et conception ce que vous demandez de faire est impossible à cause simplement du paradox temporel. Soit la transaction est validée, soit elle est annulée. Une fois validée on ne peut décider de revenir en arrière pour l'annuler car d'autres opérations ont pu être faites depuis.
Je ne suis pas d'accord. Et d'ailleurs ce que je veux faire porte un nom, on appelle ca une compensation. Il est évident qu'il faut prendre des précautions et garder la notion "d'isolation" dans la transaction. Je veux dire par là que les données impactées par le changement ne doivent pas être modifées une deuxième fois.
Dans ce cas, pas de trigger, pas de clefs autouincrémentées, pas de transactions dans un niveau d'isolation inférieure au niveau serializable, ce qui veut dire : bonjour les performances et bonjour l'usine à gaz !!!
Imaginez simplement un compta dans laquelle on alimente une table avec le CA de la journée à minuit... Que se passe t-il si une transaction à 18h est annulée le lendemain ???
Oui c'est vrai. Mais voir la remarque précédente.
Il n'existe pas non plus d'outils tiers pour ce faire et pour les mêmes raisons, car le base sera fatalement incohérente.
Sauf si l'isoltaion est garantie.
Visiblement vous avez une problème de conception fonctionnelle !
Non mais il est vrai que ce que je dois faire c'est non pas de modifier des tables mais de créer des instances, de les relier à un objet "travail", puis en partant de cet objet travail, d'effacer toutes les nouvelles instances créées si besoin. Parce que garantir l'isolation, hum j'ai des doutes...dans l'opérationnel...
Prenez un bon cours sur les SGBDR cela fait maintenant 27 ans que cela marche et très bien. Des centaines de milliard de transactions sont faites tous les jours dans tous les SGBDR de la planète et cela sans aucun défaut d'isolation, sauf l'erreur de codage du développeur !
Votre éclatant manque de culture vous fait poser des questions qui n'ont aucun sens et ont été résolé dans les années 70/80 par les chercheurs comme Codd, Date, Stonebraker pour ne citer qu'eux ! Et ces solutions sont aujourd'hui en oeuvre dans les SGBDR comme oracle, SQL Server ou IBM DB2 depuis 2 décénnies...
A +
A +
Merci de votre aide
Oriane
-- 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 ***********************
Oriane
"Fred BROUARD" a écrit dans le message de news: ...
Prenez un bon cours sur les SGBDR cela fait maintenant 27 ans que cela marche et très bien. Des centaines de milliard de transactions sont faites tous les jours dans tous les SGBDR de la planète et cela sans aucun défaut d'isolation, sauf l'erreur de codage du développeur !
Je crois qu'on ne s'est pas compris. Je ne remets pas en cause la technologie des SGBDR.
Votre éclatant manque de culture vous fait poser des questions qui n'ont aucun sens et ont été résolé dans les années 70/80 par les chercheurs comme Codd, Date, Stonebraker pour ne citer qu'eux !
Si vous le dites.
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
news:OFxE0qtoHHA.588@TK2MSFTNGP06.phx.gbl...
...
Prenez un bon cours sur les SGBDR cela fait maintenant 27 ans que cela
marche et très bien. Des centaines de milliard de transactions sont faites
tous les jours dans tous les SGBDR de la planète et cela sans aucun défaut
d'isolation, sauf l'erreur de codage du développeur !
Je crois qu'on ne s'est pas compris. Je ne remets pas en cause la
technologie des SGBDR.
Votre éclatant manque de culture vous fait poser des questions qui n'ont
aucun sens et ont été résolé dans les années 70/80 par les chercheurs
comme Codd, Date, Stonebraker pour ne citer qu'eux !
"Fred BROUARD" a écrit dans le message de news: ...
Prenez un bon cours sur les SGBDR cela fait maintenant 27 ans que cela marche et très bien. Des centaines de milliard de transactions sont faites tous les jours dans tous les SGBDR de la planète et cela sans aucun défaut d'isolation, sauf l'erreur de codage du développeur !
Je crois qu'on ne s'est pas compris. Je ne remets pas en cause la technologie des SGBDR.
Votre éclatant manque de culture vous fait poser des questions qui n'ont aucun sens et ont été résolé dans les années 70/80 par les chercheurs comme Codd, Date, Stonebraker pour ne citer qu'eux !
