Michel Billaud disait ceci en ce jour du 30.09.2006 22:04:Autre hypothèse, vous prenez comme "date de transaction" la date
(unique) à la microseconde de la fabrication du formulaire. Et là,
vous êtes en train de réinventer le jeton.
Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
La date ( à la micro-seconde, seconde, ...., année ) est un objet qui
modélise le monde réel et non un jeton qui est, si j'ai bien compris,
une astuce technique.
J'ajoute que j'ai pris l'exemple de la date, mais ce pourrait être un
numéro de transaction bancaire ( qui n'a rien à voir avec un numéro
d'ordre dans la base de données ) si l'analyse a montré que c'est
comme ça que ça fonctionne dans la réalité.
De toute façon, vous ne pouvez créer de table qui n'ait pas de clé,
sinon votre analyse est mauvaise et M. Codd ne sera pas d'accord.
Michel Billaud disait ceci en ce jour du 30.09.2006 22:04:
Autre hypothèse, vous prenez comme "date de transaction" la date
(unique) à la microseconde de la fabrication du formulaire. Et là,
vous êtes en train de réinventer le jeton.
Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
La date ( à la micro-seconde, seconde, ...., année ) est un objet qui
modélise le monde réel et non un jeton qui est, si j'ai bien compris,
une astuce technique.
J'ajoute que j'ai pris l'exemple de la date, mais ce pourrait être un
numéro de transaction bancaire ( qui n'a rien à voir avec un numéro
d'ordre dans la base de données ) si l'analyse a montré que c'est
comme ça que ça fonctionne dans la réalité.
De toute façon, vous ne pouvez créer de table qui n'ait pas de clé,
sinon votre analyse est mauvaise et M. Codd ne sera pas d'accord.
Michel Billaud disait ceci en ce jour du 30.09.2006 22:04:Autre hypothèse, vous prenez comme "date de transaction" la date
(unique) à la microseconde de la fabrication du formulaire. Et là,
vous êtes en train de réinventer le jeton.
Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
La date ( à la micro-seconde, seconde, ...., année ) est un objet qui
modélise le monde réel et non un jeton qui est, si j'ai bien compris,
une astuce technique.
J'ajoute que j'ai pris l'exemple de la date, mais ce pourrait être un
numéro de transaction bancaire ( qui n'a rien à voir avec un numéro
d'ordre dans la base de données ) si l'analyse a montré que c'est
comme ça que ça fonctionne dans la réalité.
De toute façon, vous ne pouvez créer de table qui n'ait pas de clé,
sinon votre analyse est mauvaise et M. Codd ne sera pas d'accord.
Tout d'abord, j'avais déjà envoyé une réponse; ne la voyant pas sur le
forum, je re-réponds. Veuillez m'excuser si les 2 réponses arrivent et
doublonnent.
Dans votre analyse, vous définissez un virement comme ceci:
(emetteur, destinataire, montant)
ce qui veut dire, dans le meilleur des cas, que vous n'autorisez,
qu'une et une seule transaction d'un montant x entre l'émetteur toto
et le destinataire titi.
Je ne pense pas que c'est ce que vous voulez, amha.
Tout d'abord, j'avais déjà envoyé une réponse; ne la voyant pas sur le
forum, je re-réponds. Veuillez m'excuser si les 2 réponses arrivent et
doublonnent.
Dans votre analyse, vous définissez un virement comme ceci:
(emetteur, destinataire, montant)
ce qui veut dire, dans le meilleur des cas, que vous n'autorisez,
qu'une et une seule transaction d'un montant x entre l'émetteur toto
et le destinataire titi.
Je ne pense pas que c'est ce que vous voulez, amha.
Tout d'abord, j'avais déjà envoyé une réponse; ne la voyant pas sur le
forum, je re-réponds. Veuillez m'excuser si les 2 réponses arrivent et
doublonnent.
Dans votre analyse, vous définissez un virement comme ceci:
(emetteur, destinataire, montant)
ce qui veut dire, dans le meilleur des cas, que vous n'autorisez,
qu'une et une seule transaction d'un montant x entre l'émetteur toto
et le destinataire titi.
Je ne pense pas que c'est ce que vous voulez, amha.
Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
Oh, excusez moi, je les ai lu vers 1980, ça remonte un peu.
Quelque chose me dit que vous confondez copieusement les bases de
données relationnelles, et la théorie d' "algèbre relationnelle" qui
en est un modèle théorique. Il y a quelques différences, par exemple
d'une relation est un ensemble (non-ordonné, sans répétition) de
n-uplets, là om une table est une suite (plus ou moins ordonnée, avec
doublons éventuesl) de n-uplets. Mais c'est pas du tout pareil (c'est
comme quand on dégaine les clauses de Horn et la résolution de
Robinson pour parler de programmation Prolog)
Souvent, la théorie relationnelle est exposée dans les bouquins pour
pouvoir montrer que les opérations relationnelles ont la même
puissance d'expression que les opérateurs algébriques (jointure,
projection, sélection, différence...). Chose dont tout le monde, de
nos jours, est convaincu (ou se contrefout, faut bien dire, autant que
du théorême d'Armstrong), mais les bouquins ont tendance à réaccomoder
les mêmes restes sans trop varier la sauce depuis 20 ans.
La date ( à la micro-seconde, seconde, ...., année ) est un objet qui
modélise le monde réel et non un jeton qui est, si j'ai bien compris,
une astuce technique.
Un jeton modélise quelque chose aussi.
J'ajoute que j'ai pris l'exemple de la date, mais ce pourrait être un
numéro de transaction bancaire ( qui n'a rien à voir avec un numéro
d'ordre dans la base de données ) si l'analyse a montré que c'est
comme ça que ça fonctionne dans la réalité.
Vous attribuez des numéros de transaction bancaire avant
que la transaction soit enregistrée de façon automatique,
vous vous en servez donc comme jeton.
De toute façon, vous ne pouvez créer de table qui n'ait pas de clé,
Oh ?
:~$ mysql test
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 9 to server version: 4.0.24_Debian-10sarge2-log
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> create table takacroire (truc integer);
Query OK, 0 rows affected (0.24 sec)
mysql> insert into takacroire values (42),(42),(42);
Query OK, 3 rows affected (0.11 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from takacroire;
+------+
| truc |
+------+
| 42 |
| 42 |
| 42 |
+------+
3 rows in set (0.00 sec)
sinon votre analyse est mauvaise et M. Codd ne sera pas d'accord.
Le regretté Codd a quitté cette vallée de larmes en 2003, et je ne
crois pas que son fantome viendra nous tirer les pieds la nuit, ni moi
pour mes piètres analyses supposées, ni vous pour vos confusions entre
théorie, possibilités pratiques, et recommandations d'usage.
Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
Oh, excusez moi, je les ai lu vers 1980, ça remonte un peu.
Quelque chose me dit que vous confondez copieusement les bases de
données relationnelles, et la théorie d' "algèbre relationnelle" qui
en est un modèle théorique. Il y a quelques différences, par exemple
d'une relation est un ensemble (non-ordonné, sans répétition) de
n-uplets, là om une table est une suite (plus ou moins ordonnée, avec
doublons éventuesl) de n-uplets. Mais c'est pas du tout pareil (c'est
comme quand on dégaine les clauses de Horn et la résolution de
Robinson pour parler de programmation Prolog)
Souvent, la théorie relationnelle est exposée dans les bouquins pour
pouvoir montrer que les opérations relationnelles ont la même
puissance d'expression que les opérateurs algébriques (jointure,
projection, sélection, différence...). Chose dont tout le monde, de
nos jours, est convaincu (ou se contrefout, faut bien dire, autant que
du théorême d'Armstrong), mais les bouquins ont tendance à réaccomoder
les mêmes restes sans trop varier la sauce depuis 20 ans.
La date ( à la micro-seconde, seconde, ...., année ) est un objet qui
modélise le monde réel et non un jeton qui est, si j'ai bien compris,
une astuce technique.
Un jeton modélise quelque chose aussi.
J'ajoute que j'ai pris l'exemple de la date, mais ce pourrait être un
numéro de transaction bancaire ( qui n'a rien à voir avec un numéro
d'ordre dans la base de données ) si l'analyse a montré que c'est
comme ça que ça fonctionne dans la réalité.
Vous attribuez des numéros de transaction bancaire avant
que la transaction soit enregistrée de façon automatique,
vous vous en servez donc comme jeton.
De toute façon, vous ne pouvez créer de table qui n'ait pas de clé,
Oh ?
billaud@wallace:~$ mysql test
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 9 to server version: 4.0.24_Debian-10sarge2-log
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> create table takacroire (truc integer);
Query OK, 0 rows affected (0.24 sec)
mysql> insert into takacroire values (42),(42),(42);
Query OK, 3 rows affected (0.11 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from takacroire;
+------+
| truc |
+------+
| 42 |
| 42 |
| 42 |
+------+
3 rows in set (0.00 sec)
sinon votre analyse est mauvaise et M. Codd ne sera pas d'accord.
Le regretté Codd a quitté cette vallée de larmes en 2003, et je ne
crois pas que son fantome viendra nous tirer les pieds la nuit, ni moi
pour mes piètres analyses supposées, ni vous pour vos confusions entre
théorie, possibilités pratiques, et recommandations d'usage.
Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
Oh, excusez moi, je les ai lu vers 1980, ça remonte un peu.
Quelque chose me dit que vous confondez copieusement les bases de
données relationnelles, et la théorie d' "algèbre relationnelle" qui
en est un modèle théorique. Il y a quelques différences, par exemple
d'une relation est un ensemble (non-ordonné, sans répétition) de
n-uplets, là om une table est une suite (plus ou moins ordonnée, avec
doublons éventuesl) de n-uplets. Mais c'est pas du tout pareil (c'est
comme quand on dégaine les clauses de Horn et la résolution de
Robinson pour parler de programmation Prolog)
Souvent, la théorie relationnelle est exposée dans les bouquins pour
pouvoir montrer que les opérations relationnelles ont la même
puissance d'expression que les opérateurs algébriques (jointure,
projection, sélection, différence...). Chose dont tout le monde, de
nos jours, est convaincu (ou se contrefout, faut bien dire, autant que
du théorême d'Armstrong), mais les bouquins ont tendance à réaccomoder
les mêmes restes sans trop varier la sauce depuis 20 ans.
La date ( à la micro-seconde, seconde, ...., année ) est un objet qui
modélise le monde réel et non un jeton qui est, si j'ai bien compris,
une astuce technique.
Un jeton modélise quelque chose aussi.
J'ajoute que j'ai pris l'exemple de la date, mais ce pourrait être un
numéro de transaction bancaire ( qui n'a rien à voir avec un numéro
d'ordre dans la base de données ) si l'analyse a montré que c'est
comme ça que ça fonctionne dans la réalité.
Vous attribuez des numéros de transaction bancaire avant
que la transaction soit enregistrée de façon automatique,
vous vous en servez donc comme jeton.
De toute façon, vous ne pouvez créer de table qui n'ait pas de clé,
Oh ?
:~$ mysql test
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 9 to server version: 4.0.24_Debian-10sarge2-log
Type 'help;' or 'h' for help. Type 'c' to clear the buffer.
mysql> create table takacroire (truc integer);
Query OK, 0 rows affected (0.24 sec)
mysql> insert into takacroire values (42),(42),(42);
Query OK, 3 rows affected (0.11 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from takacroire;
+------+
| truc |
+------+
| 42 |
| 42 |
| 42 |
+------+
3 rows in set (0.00 sec)
sinon votre analyse est mauvaise et M. Codd ne sera pas d'accord.
Le regretté Codd a quitté cette vallée de larmes en 2003, et je ne
crois pas que son fantome viendra nous tirer les pieds la nuit, ni moi
pour mes piètres analyses supposées, ni vous pour vos confusions entre
théorie, possibilités pratiques, et recommandations d'usage.
Michel Billaud disait ceci en ce jour du 02.10.2006 20:43:Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
Oh, excusez moi, je les ai lu vers 1980, ça remonte un peu.
Heureux de vous rafraîchir la mémoire :-) .
Non, je ne confonds pas la théorie de l'algèbre relationnelle et les
SGBD relationnels.
Pour reprendre les dires de M. Gardarin ( oui, c'est vrai, j'aime bien
ses ouvrages), l'algèbre relationnelle est l'outil formel
indispensable pour manipuler les relations.
Les SGBD relationnels sont basés sur le modèle relationnel et
permettent de structurer les données sous forme de tables à 2
dimensions.
En ce qui concerne la relation, je ne suis pas d'accord avec vous: une
relation s'exprime sous forme de table dans un SGBD.
Exemple de relation dans le modèle relationnel:
r ={ (Dupont,Paris,2140), (Durand,Orsay,1128), ....} (cf Modélisation
dans la conception des systèmes d'information par Acsiome chez Masson )
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Dans ce modèle, la relation se situe au plan conceptuel et la table au
plan applicatif.
Définition ( issue de Apprendre et pratiquer Merise chez Masson ): une
relation entre objets ( ou individus ) est une association perçue dans
le réel entre 2 ou plusieurs entités. Une relation est dépourvue
d'existence propre.
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Veuillez m'excuser, mais je ne connais pas la définition du jeton ( à
part dans les réseaux Token-ring ...).
Quand aux numéros de transaction bancaire que je prends en exemple, je
ne m'en sert que s'ils existent dans les règles de gestion de la
banque.
Il ne s'agit pas d'une astuce technique informatique pour différencier
2 transactions bancaires.
Je n'ai pas dit, ce me semble, que ce genre de table était rejeté par
un SGBD relationnel; j'ai dit qu'une table devait toujours contenir
une clé, sinon l'analyse était mauvaise. Ce qui est différent.
Michel Billaud disait ceci en ce jour du 02.10.2006 20:43:
Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
Oh, excusez moi, je les ai lu vers 1980, ça remonte un peu.
Heureux de vous rafraîchir la mémoire :-) .
Non, je ne confonds pas la théorie de l'algèbre relationnelle et les
SGBD relationnels.
Pour reprendre les dires de M. Gardarin ( oui, c'est vrai, j'aime bien
ses ouvrages), l'algèbre relationnelle est l'outil formel
indispensable pour manipuler les relations.
Les SGBD relationnels sont basés sur le modèle relationnel et
permettent de structurer les données sous forme de tables à 2
dimensions.
En ce qui concerne la relation, je ne suis pas d'accord avec vous: une
relation s'exprime sous forme de table dans un SGBD.
Exemple de relation dans le modèle relationnel:
r ={ (Dupont,Paris,2140), (Durand,Orsay,1128), ....} (cf Modélisation
dans la conception des systèmes d'information par Acsiome chez Masson )
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Dans ce modèle, la relation se situe au plan conceptuel et la table au
plan applicatif.
Définition ( issue de Apprendre et pratiquer Merise chez Masson ): une
relation entre objets ( ou individus ) est une association perçue dans
le réel entre 2 ou plusieurs entités. Une relation est dépourvue
d'existence propre.
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Veuillez m'excuser, mais je ne connais pas la définition du jeton ( à
part dans les réseaux Token-ring ...).
Quand aux numéros de transaction bancaire que je prends en exemple, je
ne m'en sert que s'ils existent dans les règles de gestion de la
banque.
Il ne s'agit pas d'une astuce technique informatique pour différencier
2 transactions bancaires.
Je n'ai pas dit, ce me semble, que ce genre de table était rejeté par
un SGBD relationnel; j'ai dit qu'une table devait toujours contenir
une clé, sinon l'analyse était mauvaise. Ce qui est différent.
Michel Billaud disait ceci en ce jour du 02.10.2006 20:43:Je ne ré-invente rien du tout, il suffit de lire n'importe quel
ouvrage sur Merise ou sur les SGD relationnels.
Oh, excusez moi, je les ai lu vers 1980, ça remonte un peu.
Heureux de vous rafraîchir la mémoire :-) .
Non, je ne confonds pas la théorie de l'algèbre relationnelle et les
SGBD relationnels.
Pour reprendre les dires de M. Gardarin ( oui, c'est vrai, j'aime bien
ses ouvrages), l'algèbre relationnelle est l'outil formel
indispensable pour manipuler les relations.
Les SGBD relationnels sont basés sur le modèle relationnel et
permettent de structurer les données sous forme de tables à 2
dimensions.
En ce qui concerne la relation, je ne suis pas d'accord avec vous: une
relation s'exprime sous forme de table dans un SGBD.
Exemple de relation dans le modèle relationnel:
r ={ (Dupont,Paris,2140), (Durand,Orsay,1128), ....} (cf Modélisation
dans la conception des systèmes d'information par Acsiome chez Masson )
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Dans ce modèle, la relation se situe au plan conceptuel et la table au
plan applicatif.
Définition ( issue de Apprendre et pratiquer Merise chez Masson ): une
relation entre objets ( ou individus ) est une association perçue dans
le réel entre 2 ou plusieurs entités. Une relation est dépourvue
d'existence propre.
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Veuillez m'excuser, mais je ne connais pas la définition du jeton ( à
part dans les réseaux Token-ring ...).
Quand aux numéros de transaction bancaire que je prends en exemple, je
ne m'en sert que s'ils existent dans les règles de gestion de la
banque.
Il ne s'agit pas d'une astuce technique informatique pour différencier
2 transactions bancaires.
Je n'ai pas dit, ce me semble, que ce genre de table était rejeté par
un SGBD relationnel; j'ai dit qu'une table devait toujours contenir
une clé, sinon l'analyse était mauvaise. Ce qui est différent.
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
.............notions
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
.............notions
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
.............notions
Larroque writes:
Pour reprendre les dires de M. Gardarin ( oui, c'est vrai, j'aime bien
ses ouvrages), l'algèbre relationnelle est l'outil formel
indispensable pour manipuler les relations.
ce n'est pas moi qui reprocherai à M. Gardarin de faire la promotion
de l'algèbre en général. Mais là vous tournez en rond, parce que
relations != tables. Il aurait parlé de l'algèbre tabulaire, ç'aurait
été différent.
Les SGBD relationnels sont basés sur le modèle relationnel et
permettent de structurer les données sous forme de tables à 2
dimensions.
En ce qui concerne la relation, je ne suis pas d'accord avec vous: une
relation s'exprime sous forme de table dans un SGBD.
Elle s'implémente. Et à condition bien sur de ne vouloir considérer
que des relations finies, définies en extension.
Exemple de relation dans le modèle relationnel:
r ={ (Dupont,Paris,2140), (Durand,Orsay,1128), ....} (cf Modélisation
dans la conception des systèmes d'information par Acsiome chez Masson )
Vous sautez de la théorie relationnelle, aux sgbd et maintenant à la
modélisation. Quelle confusion !
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Je vous rassure, Gardarin a parfaitement raison. Enfin, si il a dit
précisément que le langage SQL, dans sa partie LDD, permet d'exprimer
des ordres de création de *tables* dans une base. Si il a écrit que
SQL créait des *relations*, ce qui m'étonnerait, c'est le goudron et
les plumes.
Dans ce modèle, la relation se situe au plan conceptuel et la table au
plan applicatif.
Comme quoi, déjà, ce n'est pas tout à fait la même chose, si on
distingue les deux.
Définition ( issue de Apprendre et pratiquer Merise chez Masson ): une
relation entre objets ( ou individus ) est une association perçue dans
le réel entre 2 ou plusieurs entités. Une relation est dépourvue
d'existence propre.
Manque de chance, les individus et les objets n'ont pas non plus
d'existence propre, si on y réfléchit bien. Ni vous ni moi :-)
http://fr.wikipedia.org/wiki/Vacuit%C3%A9
Vous savez, tout ce baratin des bouquins des methodes d'analyse est
assez approximatif. Ce n'est pas parce que c'est présenté à grands coups
de "définition" que ça tient debout quand on gratte un peu.
Prenez par exemple "une association perçue dans le monde réel entre
entités".
Si on veut jouer à "définition", il faut d'abord définir "entité".
qu'appelez-vous le monde réel ? Le premier janvier 12765376577868 av
JC est elle une date du monde réel ? Décrire une relation comme une
association, n'est-ce pas jouer avec les mots ? (je me rappelle,
quand j'étais petit un cours de 6ieme commençant par "def: un ensemble
est une classe d'objets ...", et là j'ai demandé "c'est quoi une
classe, exactement ?" :-)). Et "perçue", par qui ? percevons nous
tous la même chose en ce qui concerne le degré de réalité d'une
entité? Une entité existe-t-elle si elle n'est pas perçue ? Une date
a-t-elle une réalité, ou n'est ce finalement qu'une pure convention
pour le répérage d'évènements dans l'espace-temps ? etc.
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
réel comme des choses "concrètes" (client, facture, commande...), vous
leur donnez le statut d'entité, vous les dessinez dans des rectangles
puis pour le reste, vous dites que c'est des relations entre les
entités. Et quand ça va pas, vous vous débrouillez comme vous pouvez
en créant des entités au statut intermédiaire (notion de ligne de
facture, par exemple)
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Dans le cas qui nous concerne, c'est une information qui permet
d'identifier une partie d'une interaction qui se concluera (peut être)
par un ajout dans une table, information employée de façon à éviter
que certaines parties de cette interaction soient "rejouées" (ce qui
conduirait à une tentative d'insertion d'un doublon).
Veuillez m'excuser, mais je ne connais pas la définition du jeton ( à
part dans les réseaux Token-ring ...).
Si définition il y a, ça doit se trouver dans les Tanenbaum consacrés
au réseau, du côté de la crypto. Désolé, j'ai prêté mon exemplaire.
Quand aux numéros de transaction bancaire que je prends en exemple, je
ne m'en sert que s'ils existent dans les règles de gestion de la
banque.
Il ne s'agit pas d'une astuce technique informatique pour différencier
2 transactions bancaires.
C'est une astuce technique pour différencier deux transactions,
introduite il y a longtemps par les banquiers. Ca revient au même.
Je n'ai pas dit, ce me semble, que ce genre de table était rejeté par
un SGBD relationnel; j'ai dit qu'une table devait toujours contenir
une clé, sinon l'analyse était mauvaise. Ce qui est différent.
Ah, vous voulez dire qu'il est souhaitable qu'à l'issue de la
conception d'un modèle relationnel, chaque table se trouve munie d'une
clé, fut-elle un auto-increment, pour pouvoir repérer les
enregistrements individuellement par leur contenu ? Dans mes bras !
Larroque <pierre.larroque@midimedia.org> writes:
Pour reprendre les dires de M. Gardarin ( oui, c'est vrai, j'aime bien
ses ouvrages), l'algèbre relationnelle est l'outil formel
indispensable pour manipuler les relations.
ce n'est pas moi qui reprocherai à M. Gardarin de faire la promotion
de l'algèbre en général. Mais là vous tournez en rond, parce que
relations != tables. Il aurait parlé de l'algèbre tabulaire, ç'aurait
été différent.
Les SGBD relationnels sont basés sur le modèle relationnel et
permettent de structurer les données sous forme de tables à 2
dimensions.
En ce qui concerne la relation, je ne suis pas d'accord avec vous: une
relation s'exprime sous forme de table dans un SGBD.
Elle s'implémente. Et à condition bien sur de ne vouloir considérer
que des relations finies, définies en extension.
Exemple de relation dans le modèle relationnel:
r ={ (Dupont,Paris,2140), (Durand,Orsay,1128), ....} (cf Modélisation
dans la conception des systèmes d'information par Acsiome chez Masson )
Vous sautez de la théorie relationnelle, aux sgbd et maintenant à la
modélisation. Quelle confusion !
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Je vous rassure, Gardarin a parfaitement raison. Enfin, si il a dit
précisément que le langage SQL, dans sa partie LDD, permet d'exprimer
des ordres de création de *tables* dans une base. Si il a écrit que
SQL créait des *relations*, ce qui m'étonnerait, c'est le goudron et
les plumes.
Dans ce modèle, la relation se situe au plan conceptuel et la table au
plan applicatif.
Comme quoi, déjà, ce n'est pas tout à fait la même chose, si on
distingue les deux.
Définition ( issue de Apprendre et pratiquer Merise chez Masson ): une
relation entre objets ( ou individus ) est une association perçue dans
le réel entre 2 ou plusieurs entités. Une relation est dépourvue
d'existence propre.
Manque de chance, les individus et les objets n'ont pas non plus
d'existence propre, si on y réfléchit bien. Ni vous ni moi :-)
http://fr.wikipedia.org/wiki/Vacuit%C3%A9
Vous savez, tout ce baratin des bouquins des methodes d'analyse est
assez approximatif. Ce n'est pas parce que c'est présenté à grands coups
de "définition" que ça tient debout quand on gratte un peu.
Prenez par exemple "une association perçue dans le monde réel entre
entités".
Si on veut jouer à "définition", il faut d'abord définir "entité".
qu'appelez-vous le monde réel ? Le premier janvier 12765376577868 av
JC est elle une date du monde réel ? Décrire une relation comme une
association, n'est-ce pas jouer avec les mots ? (je me rappelle,
quand j'étais petit un cours de 6ieme commençant par "def: un ensemble
est une classe d'objets ...", et là j'ai demandé "c'est quoi une
classe, exactement ?" :-)). Et "perçue", par qui ? percevons nous
tous la même chose en ce qui concerne le degré de réalité d'une
entité? Une entité existe-t-elle si elle n'est pas perçue ? Une date
a-t-elle une réalité, ou n'est ce finalement qu'une pure convention
pour le répérage d'évènements dans l'espace-temps ? etc.
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
réel comme des choses "concrètes" (client, facture, commande...), vous
leur donnez le statut d'entité, vous les dessinez dans des rectangles
puis pour le reste, vous dites que c'est des relations entre les
entités. Et quand ça va pas, vous vous débrouillez comme vous pouvez
en créant des entités au statut intermédiaire (notion de ligne de
facture, par exemple)
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Dans le cas qui nous concerne, c'est une information qui permet
d'identifier une partie d'une interaction qui se concluera (peut être)
par un ajout dans une table, information employée de façon à éviter
que certaines parties de cette interaction soient "rejouées" (ce qui
conduirait à une tentative d'insertion d'un doublon).
Veuillez m'excuser, mais je ne connais pas la définition du jeton ( à
part dans les réseaux Token-ring ...).
Si définition il y a, ça doit se trouver dans les Tanenbaum consacrés
au réseau, du côté de la crypto. Désolé, j'ai prêté mon exemplaire.
Quand aux numéros de transaction bancaire que je prends en exemple, je
ne m'en sert que s'ils existent dans les règles de gestion de la
banque.
Il ne s'agit pas d'une astuce technique informatique pour différencier
2 transactions bancaires.
C'est une astuce technique pour différencier deux transactions,
introduite il y a longtemps par les banquiers. Ca revient au même.
Je n'ai pas dit, ce me semble, que ce genre de table était rejeté par
un SGBD relationnel; j'ai dit qu'une table devait toujours contenir
une clé, sinon l'analyse était mauvaise. Ce qui est différent.
Ah, vous voulez dire qu'il est souhaitable qu'à l'issue de la
conception d'un modèle relationnel, chaque table se trouve munie d'une
clé, fut-elle un auto-increment, pour pouvoir repérer les
enregistrements individuellement par leur contenu ? Dans mes bras !
Larroque writes:
Pour reprendre les dires de M. Gardarin ( oui, c'est vrai, j'aime bien
ses ouvrages), l'algèbre relationnelle est l'outil formel
indispensable pour manipuler les relations.
ce n'est pas moi qui reprocherai à M. Gardarin de faire la promotion
de l'algèbre en général. Mais là vous tournez en rond, parce que
relations != tables. Il aurait parlé de l'algèbre tabulaire, ç'aurait
été différent.
Les SGBD relationnels sont basés sur le modèle relationnel et
permettent de structurer les données sous forme de tables à 2
dimensions.
En ce qui concerne la relation, je ne suis pas d'accord avec vous: une
relation s'exprime sous forme de table dans un SGBD.
Elle s'implémente. Et à condition bien sur de ne vouloir considérer
que des relations finies, définies en extension.
Exemple de relation dans le modèle relationnel:
r ={ (Dupont,Paris,2140), (Durand,Orsay,1128), ....} (cf Modélisation
dans la conception des systèmes d'information par Acsiome chez Masson )
Vous sautez de la théorie relationnelle, aux sgbd et maintenant à la
modélisation. Quelle confusion !
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Je vous rassure, Gardarin a parfaitement raison. Enfin, si il a dit
précisément que le langage SQL, dans sa partie LDD, permet d'exprimer
des ordres de création de *tables* dans une base. Si il a écrit que
SQL créait des *relations*, ce qui m'étonnerait, c'est le goudron et
les plumes.
Dans ce modèle, la relation se situe au plan conceptuel et la table au
plan applicatif.
Comme quoi, déjà, ce n'est pas tout à fait la même chose, si on
distingue les deux.
Définition ( issue de Apprendre et pratiquer Merise chez Masson ): une
relation entre objets ( ou individus ) est une association perçue dans
le réel entre 2 ou plusieurs entités. Une relation est dépourvue
d'existence propre.
Manque de chance, les individus et les objets n'ont pas non plus
d'existence propre, si on y réfléchit bien. Ni vous ni moi :-)
http://fr.wikipedia.org/wiki/Vacuit%C3%A9
Vous savez, tout ce baratin des bouquins des methodes d'analyse est
assez approximatif. Ce n'est pas parce que c'est présenté à grands coups
de "définition" que ça tient debout quand on gratte un peu.
Prenez par exemple "une association perçue dans le monde réel entre
entités".
Si on veut jouer à "définition", il faut d'abord définir "entité".
qu'appelez-vous le monde réel ? Le premier janvier 12765376577868 av
JC est elle une date du monde réel ? Décrire une relation comme une
association, n'est-ce pas jouer avec les mots ? (je me rappelle,
quand j'étais petit un cours de 6ieme commençant par "def: un ensemble
est une classe d'objets ...", et là j'ai demandé "c'est quoi une
classe, exactement ?" :-)). Et "perçue", par qui ? percevons nous
tous la même chose en ce qui concerne le degré de réalité d'une
entité? Une entité existe-t-elle si elle n'est pas perçue ? Une date
a-t-elle une réalité, ou n'est ce finalement qu'une pure convention
pour le répérage d'évènements dans l'espace-temps ? etc.
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
réel comme des choses "concrètes" (client, facture, commande...), vous
leur donnez le statut d'entité, vous les dessinez dans des rectangles
puis pour le reste, vous dites que c'est des relations entre les
entités. Et quand ça va pas, vous vous débrouillez comme vous pouvez
en créant des entités au statut intermédiaire (notion de ligne de
facture, par exemple)
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Dans le cas qui nous concerne, c'est une information qui permet
d'identifier une partie d'une interaction qui se concluera (peut être)
par un ajout dans une table, information employée de façon à éviter
que certaines parties de cette interaction soient "rejouées" (ce qui
conduirait à une tentative d'insertion d'un doublon).
Veuillez m'excuser, mais je ne connais pas la définition du jeton ( à
part dans les réseaux Token-ring ...).
Si définition il y a, ça doit se trouver dans les Tanenbaum consacrés
au réseau, du côté de la crypto. Désolé, j'ai prêté mon exemplaire.
Quand aux numéros de transaction bancaire que je prends en exemple, je
ne m'en sert que s'ils existent dans les règles de gestion de la
banque.
Il ne s'agit pas d'une astuce technique informatique pour différencier
2 transactions bancaires.
C'est une astuce technique pour différencier deux transactions,
introduite il y a longtemps par les banquiers. Ca revient au même.
Je n'ai pas dit, ce me semble, que ce genre de table était rejeté par
un SGBD relationnel; j'ai dit qu'une table devait toujours contenir
une clé, sinon l'analyse était mauvaise. Ce qui est différent.
Ah, vous voulez dire qu'il est souhaitable qu'à l'issue de la
conception d'un modèle relationnel, chaque table se trouve munie d'une
clé, fut-elle un auto-increment, pour pouvoir repérer les
enregistrements individuellement par leur contenu ? Dans mes bras !
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Je vous rassure, Gardarin a parfaitement raison. Enfin, si il a dit
précisément que le langage SQL, dans sa partie LDD, permet d'exprimer
des ordres de création de *tables* dans une base. Si il a écrit que
SQL créait des *relations*, ce qui m'étonnerait, c'est le goudron et
les plumes.
Page 201 de "Maîtriser les bases de données" par Georges Gardarin,
édition Eyrolles (1994).
Prenez par exemple "une association perçue dans le monde réel entre
entités".
Si on veut jouer à "définition", il faut d'abord définir "entité".
je cite:
"( Acsiome ) Une entité est une classe générique d'individus ou
d'objets ayant les mêmes caractéristiques par un modélisateur placé
dans un environnement donné"
"(Gardarin) Entité: Modèle d'objet identifié du monde réel dont le
type est défini par un nom et une liste de propriétés"
Je rappelle que nous parlons de conception de systèmes d'information
et non de philosophie.
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
réel comme des choses "concrètes" (client, facture, commande...), vous
leur donnez le statut d'entité, vous les dessinez dans des rectangles
puis pour le reste, vous dites que c'est des relations entre les
entités. Et quand ça va pas, vous vous débrouillez comme vous pouvez
en créant des entités au statut intermédiaire (notion de ligne de
facture, par exemple)
Bien résumé. Mais c'est ce à quoi amènent les théories de modélisation
de SI ( c'est pour ça qu'elles ont été faites, non ? ).
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Dans le cas qui nous concerne, c'est une information qui permet
d'identifier une partie d'une interaction qui se concluera (peut être)
par un ajout dans une table, information employée de façon à éviter
que certaines parties de cette interaction soient "rejouées" (ce qui
conduirait à une tentative d'insertion d'un doublon).
Mais, un SGBD relationnel permet ceci sans jeton ( si j'ai bien
compris votre définition ) !! C'est justement le rôle des clés, des
contraintes et des transactions.
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Je vous rassure, Gardarin a parfaitement raison. Enfin, si il a dit
précisément que le langage SQL, dans sa partie LDD, permet d'exprimer
des ordres de création de *tables* dans une base. Si il a écrit que
SQL créait des *relations*, ce qui m'étonnerait, c'est le goudron et
les plumes.
Page 201 de "Maîtriser les bases de données" par Georges Gardarin,
édition Eyrolles (1994).
Prenez par exemple "une association perçue dans le monde réel entre
entités".
Si on veut jouer à "définition", il faut d'abord définir "entité".
je cite:
"( Acsiome ) Une entité est une classe générique d'individus ou
d'objets ayant les mêmes caractéristiques par un modélisateur placé
dans un environnement donné"
"(Gardarin) Entité: Modèle d'objet identifié du monde réel dont le
type est défini par un nom et une liste de propriétés"
Je rappelle que nous parlons de conception de systèmes d'information
et non de philosophie.
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
réel comme des choses "concrètes" (client, facture, commande...), vous
leur donnez le statut d'entité, vous les dessinez dans des rectangles
puis pour le reste, vous dites que c'est des relations entre les
entités. Et quand ça va pas, vous vous débrouillez comme vous pouvez
en créant des entités au statut intermédiaire (notion de ligne de
facture, par exemple)
Bien résumé. Mais c'est ce à quoi amènent les théories de modélisation
de SI ( c'est pour ça qu'elles ont été faites, non ? ).
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Dans le cas qui nous concerne, c'est une information qui permet
d'identifier une partie d'une interaction qui se concluera (peut être)
par un ajout dans une table, information employée de façon à éviter
que certaines parties de cette interaction soient "rejouées" (ce qui
conduirait à une tentative d'insertion d'un doublon).
Mais, un SGBD relationnel permet ceci sans jeton ( si j'ai bien
compris votre définition ) !! C'est justement le rôle des clés, des
contraintes et des transactions.
D'ailleurs, il est dit, par le même auteur ( Gardarin ), que le
langage SQL permet de créer des relations sous forme de table.
Je vous rassure, Gardarin a parfaitement raison. Enfin, si il a dit
précisément que le langage SQL, dans sa partie LDD, permet d'exprimer
des ordres de création de *tables* dans une base. Si il a écrit que
SQL créait des *relations*, ce qui m'étonnerait, c'est le goudron et
les plumes.
Page 201 de "Maîtriser les bases de données" par Georges Gardarin,
édition Eyrolles (1994).
Prenez par exemple "une association perçue dans le monde réel entre
entités".
Si on veut jouer à "définition", il faut d'abord définir "entité".
je cite:
"( Acsiome ) Une entité est une classe générique d'individus ou
d'objets ayant les mêmes caractéristiques par un modélisateur placé
dans un environnement donné"
"(Gardarin) Entité: Modèle d'objet identifié du monde réel dont le
type est défini par un nom et une liste de propriétés"
Je rappelle que nous parlons de conception de systèmes d'information
et non de philosophie.
bref, c'est du baratin pour dire : en gros, pour modéliser, vous
prenez les notations qui sont habituellement repérées dans le monde
réel comme des choses "concrètes" (client, facture, commande...), vous
leur donnez le statut d'entité, vous les dessinez dans des rectangles
puis pour le reste, vous dites que c'est des relations entre les
entités. Et quand ça va pas, vous vous débrouillez comme vous pouvez
en créant des entités au statut intermédiaire (notion de ligne de
facture, par exemple)
Bien résumé. Mais c'est ce à quoi amènent les théories de modélisation
de SI ( c'est pour ça qu'elles ont été faites, non ? ).
Un jeton modélise quelque chose aussi.
Quoi ? ( dans le mode réel, je rappelle ).
Dans le cas qui nous concerne, c'est une information qui permet
d'identifier une partie d'une interaction qui se concluera (peut être)
par un ajout dans une table, information employée de façon à éviter
que certaines parties de cette interaction soient "rejouées" (ce qui
conduirait à une tentative d'insertion d'un doublon).
Mais, un SGBD relationnel permet ceci sans jeton ( si j'ai bien
compris votre définition ) !! C'est justement le rôle des clés, des
contraintes et des transactions.
Et bien, ce n'est pas le premier à écrire une connerie dans un bouquin.
..............
Super. On a un mot à définir, entité, et maintenant il faut définir
"objet", "individu", et "classe", qui plus est "générique". Et quel
est le modélisateur, quel est l'environnement auquel on se
réfère. Tout ça c'est nécessaire pour que deux modélisateurs voient à
peu près les mêmes entités dans une réalité qui est censée leur être
commune, histoire de pouvoir communiquer, voire collaborer.
.....................
Là on n'est plus dans le monde réel, mais dans le modèle.
..................
La philosophie est une chose très sérieuse.
.............
En pratique, ce genre de théorie est faite
- au début, pour que l'inventeur fasse des tas de papiers qui lui
permettront d'assister à des conférences qui ont lieu dans des
endroits exotiques, et d'obtenir un poste plus élevé.
- ensuite, pour que ceux qui la promeuvent se fassent des c* en or en
vendant leurs salades dans des séminaires de formation
- et à la fin, pour les rares qui se sont bien vendues, parce qu'elles
constituent un langage commun qui permet de collaborer sur un projet.
.................
Mais, un SGBD relationnel permet ceci sans jeton ( si j'ai bien
compris votre définition ) !! C'est justement le rôle des clés, des
contraintes et des transactions.
Revenez à l'exemple, le jeton est un truc qui est dans le formulaire,
et qui revient au serveur pour controle. Le SGBD n'a rien a voir la
dedans, il ne s'occupe pas du conversationnel avec l'usager.
Et bien, ce n'est pas le premier à écrire une connerie dans un bouquin.
..............
Super. On a un mot à définir, entité, et maintenant il faut définir
"objet", "individu", et "classe", qui plus est "générique". Et quel
est le modélisateur, quel est l'environnement auquel on se
réfère. Tout ça c'est nécessaire pour que deux modélisateurs voient à
peu près les mêmes entités dans une réalité qui est censée leur être
commune, histoire de pouvoir communiquer, voire collaborer.
.....................
Là on n'est plus dans le monde réel, mais dans le modèle.
..................
La philosophie est une chose très sérieuse.
.............
En pratique, ce genre de théorie est faite
- au début, pour que l'inventeur fasse des tas de papiers qui lui
permettront d'assister à des conférences qui ont lieu dans des
endroits exotiques, et d'obtenir un poste plus élevé.
- ensuite, pour que ceux qui la promeuvent se fassent des c* en or en
vendant leurs salades dans des séminaires de formation
- et à la fin, pour les rares qui se sont bien vendues, parce qu'elles
constituent un langage commun qui permet de collaborer sur un projet.
.................
Mais, un SGBD relationnel permet ceci sans jeton ( si j'ai bien
compris votre définition ) !! C'est justement le rôle des clés, des
contraintes et des transactions.
Revenez à l'exemple, le jeton est un truc qui est dans le formulaire,
et qui revient au serveur pour controle. Le SGBD n'a rien a voir la
dedans, il ne s'occupe pas du conversationnel avec l'usager.
Et bien, ce n'est pas le premier à écrire une connerie dans un bouquin.
..............
Super. On a un mot à définir, entité, et maintenant il faut définir
"objet", "individu", et "classe", qui plus est "générique". Et quel
est le modélisateur, quel est l'environnement auquel on se
réfère. Tout ça c'est nécessaire pour que deux modélisateurs voient à
peu près les mêmes entités dans une réalité qui est censée leur être
commune, histoire de pouvoir communiquer, voire collaborer.
.....................
Là on n'est plus dans le monde réel, mais dans le modèle.
..................
La philosophie est une chose très sérieuse.
.............
En pratique, ce genre de théorie est faite
- au début, pour que l'inventeur fasse des tas de papiers qui lui
permettront d'assister à des conférences qui ont lieu dans des
endroits exotiques, et d'obtenir un poste plus élevé.
- ensuite, pour que ceux qui la promeuvent se fassent des c* en or en
vendant leurs salades dans des séminaires de formation
- et à la fin, pour les rares qui se sont bien vendues, parce qu'elles
constituent un langage commun qui permet de collaborer sur un projet.
.................
Mais, un SGBD relationnel permet ceci sans jeton ( si j'ai bien
compris votre définition ) !! C'est justement le rôle des clés, des
contraintes et des transactions.
Revenez à l'exemple, le jeton est un truc qui est dans le formulaire,
et qui revient au serveur pour controle. Le SGBD n'a rien a voir la
dedans, il ne s'occupe pas du conversationnel avec l'usager.
Puis-je quand même vous faire remarquer que sans ces théories dont
celles de Codd, vous n'auriez pas l'usage des SGBD relationnels.
2) C'est au SGBD d'empêcher les doublons par l'usage des clés,
contraintes et transactions. C'est ainsi que doit être utilisé un SGBD.
Donc, avec un SGBD, le jeton n'a pas lieu d'être. Les clés et les
contraintes définies par l'analyse du réel suffisent amplement.
Et dire qu'un SGBD relationnel n'a rien à voir dans ce que vous
appelez le conversationnel ( je présume qu'il s'agit des affichages
des formulaires de saisie et des résultats )
est vrai,
mais en ce qui
concerne les traitements et la garantie d'unicité des saisies,
il a tout à voir et ça fait partie de son boulot ......
Voir entretiens de confucius, XII.2
à quoi servent donc
les commit et rollback, les unique, primary key, foreign key ... on
delete ..., les not null, les check ...... ?????
Et je livre à votre sagacité et ironie cette introduction aux
transactions tirée de 'Client serveur' de Miranda et Ruols ( Eyrolles
):
"
2 - Les problèmes de contrôle de concurrence et de reprise sur panne:
le concept de transaction:
[...]
Puis-je quand même vous faire remarquer que sans ces théories dont
celles de Codd, vous n'auriez pas l'usage des SGBD relationnels.
2) C'est au SGBD d'empêcher les doublons par l'usage des clés,
contraintes et transactions. C'est ainsi que doit être utilisé un SGBD.
Donc, avec un SGBD, le jeton n'a pas lieu d'être. Les clés et les
contraintes définies par l'analyse du réel suffisent amplement.
Et dire qu'un SGBD relationnel n'a rien à voir dans ce que vous
appelez le conversationnel ( je présume qu'il s'agit des affichages
des formulaires de saisie et des résultats )
est vrai,
mais en ce qui
concerne les traitements et la garantie d'unicité des saisies,
il a tout à voir et ça fait partie de son boulot ......
Voir entretiens de confucius, XII.2
à quoi servent donc
les commit et rollback, les unique, primary key, foreign key ... on
delete ..., les not null, les check ...... ?????
Et je livre à votre sagacité et ironie cette introduction aux
transactions tirée de 'Client serveur' de Miranda et Ruols ( Eyrolles
):
"
2 - Les problèmes de contrôle de concurrence et de reprise sur panne:
le concept de transaction:
[...]
Puis-je quand même vous faire remarquer que sans ces théories dont
celles de Codd, vous n'auriez pas l'usage des SGBD relationnels.
2) C'est au SGBD d'empêcher les doublons par l'usage des clés,
contraintes et transactions. C'est ainsi que doit être utilisé un SGBD.
Donc, avec un SGBD, le jeton n'a pas lieu d'être. Les clés et les
contraintes définies par l'analyse du réel suffisent amplement.
Et dire qu'un SGBD relationnel n'a rien à voir dans ce que vous
appelez le conversationnel ( je présume qu'il s'agit des affichages
des formulaires de saisie et des résultats )
est vrai,
mais en ce qui
concerne les traitements et la garantie d'unicité des saisies,
il a tout à voir et ça fait partie de son boulot ......
Voir entretiens de confucius, XII.2
à quoi servent donc
les commit et rollback, les unique, primary key, foreign key ... on
delete ..., les not null, les check ...... ?????
Et je livre à votre sagacité et ironie cette introduction aux
transactions tirée de 'Client serveur' de Miranda et Ruols ( Eyrolles
):
"
2 - Les problèmes de contrôle de concurrence et de reprise sur panne:
le concept de transaction:
[...]
"
2 - Les problèmes de contrôle de concurrence et de reprise sur panne:
le concept de transaction:
[...]
Sans vouloir trop m'avancer (je n'ai pas le bouquin sous la main mais
vous pourrez vérifier pour moi), il me semble que MM. Miranda et Ruol
parlent de transactions programme-sgbd, pas de conversation
programme-utilisateur, ce qui était le problème initial.
Si c'est de l'INSERT, il suffit de choisir correctement ses clefsuniques/primaires.
"
2 - Les problèmes de contrôle de concurrence et de reprise sur panne:
le concept de transaction:
[...]
Sans vouloir trop m'avancer (je n'ai pas le bouquin sous la main mais
vous pourrez vérifier pour moi), il me semble que MM. Miranda et Ruol
parlent de transactions programme-sgbd, pas de conversation
programme-utilisateur, ce qui était le problème initial.
Si c'est de l'INSERT, il suffit de choisir correctement ses clefs
uniques/primaires.
"
2 - Les problèmes de contrôle de concurrence et de reprise sur panne:
le concept de transaction:
[...]
Sans vouloir trop m'avancer (je n'ai pas le bouquin sous la main mais
vous pourrez vérifier pour moi), il me semble que MM. Miranda et Ruol
parlent de transactions programme-sgbd, pas de conversation
programme-utilisateur, ce qui était le problème initial.
Si c'est de l'INSERT, il suffit de choisir correctement ses clefsuniques/primaires.
