Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Michel Billaud disait ceci en ce jour du 18.09.2006 16:29:Si c'est de l'INSERT, il suffit de choisir correctement ses clefs
uniques/primaires.
Quand y en a, et y en a pas toujours.
Contre-exemple, un site genre banque pour rire où il y a des
"virements" à faire d'un compte à un autre. On n'attribue pas un
identifiant a priori à chaque virement, donc si on reposte l'ordre de
virement (emetteur, destinataire, montant), c'est pas la vérification
SQL qui y peut quelque chose... Même remarque pour l'UPDATE.
La solution est alors le jeton pour évite de re-traiter un
formulaire.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Michel Billaud disait ceci en ce jour du 18.09.2006 16:29:
Si c'est de l'INSERT, il suffit de choisir correctement ses clefs
uniques/primaires.
Quand y en a, et y en a pas toujours.
Contre-exemple, un site genre banque pour rire où il y a des
"virements" à faire d'un compte à un autre. On n'attribue pas un
identifiant a priori à chaque virement, donc si on reposte l'ordre de
virement (emetteur, destinataire, montant), c'est pas la vérification
SQL qui y peut quelque chose... Même remarque pour l'UPDATE.
La solution est alors le jeton pour évite de re-traiter un
formulaire.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Michel Billaud disait ceci en ce jour du 18.09.2006 16:29:Si c'est de l'INSERT, il suffit de choisir correctement ses clefs
uniques/primaires.
Quand y en a, et y en a pas toujours.
Contre-exemple, un site genre banque pour rire où il y a des
"virements" à faire d'un compte à un autre. On n'attribue pas un
identifiant a priori à chaque virement, donc si on reposte l'ordre de
virement (emetteur, destinataire, montant), c'est pas la vérification
SQL qui y peut quelque chose... Même remarque pour l'UPDATE.
La solution est alors le jeton pour évite de re-traiter un
formulaire.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
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.
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.
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.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Non, aucune obligation à cela.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Vu qu'une clef primaire doit avoir la propriété d'unicité et que rien
n'empêche quelqu'un de faire deux virements le même jour à la même
destination, votre n-uplet ne peut être une clef.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Non, aucune obligation à cela.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Vu qu'une clef primaire doit avoir la propriété d'unicité et que rien
n'empêche quelqu'un de faire deux virements le même jour à la même
destination, votre n-uplet ne peut être une clef.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Non, aucune obligation à cela.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Vu qu'une clef primaire doit avoir la propriété d'unicité et que rien
n'empêche quelqu'un de faire deux virements le même jour à la même
destination, votre n-uplet ne peut être une clef.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Non, aucune obligation à cela.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Vu qu'une clef primaire doit avoir la propriété d'unicité et que rien
n'empêche quelqu'un de faire deux virements le même jour à la même
destination, votre n-uplet ne peut être une clef.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Non, aucune obligation à cela.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Vu qu'une clef primaire doit avoir la propriété d'unicité et que rien
n'empêche quelqu'un de faire deux virements le même jour à la même
destination, votre n-uplet ne peut être une clef.
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Non, aucune obligation à cela.
Dans l'exemple que vous donnez il manque la date de la transaction et
l'ensemble {emetteur, destinataire, date } forme la clé de la table.
Vu qu'une clef primaire doit avoir la propriété d'unicité et que rien
n'empêche quelqu'un de faire deux virements le même jour à la même
destination, votre n-uplet ne peut être une clef.
Larroque writes:
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Au sens de la théorie relationnelle, où une table est un ensemble de
t-uples, en effet. Il devrait donc y en avoir. Ca serait bien. Mais
laquelle ?
Si vous prenez comme "date de transaction" la date+heure où
l'insertion a lieu, le renvoi du même contenu de formulaire un peu
plus tard correspond à deux insertions faites à des dates+heures
différentes.
Ou alors, si date = journée, vous interdisez à un émetteur de faire
deux transactions avec le même destinataire la même journée ? :-)
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.
Larroque <pierre.larroque@free.fr> writes:
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Au sens de la théorie relationnelle, où une table est un ensemble de
t-uples, en effet. Il devrait donc y en avoir. Ca serait bien. Mais
laquelle ?
Si vous prenez comme "date de transaction" la date+heure où
l'insertion a lieu, le renvoi du même contenu de formulaire un peu
plus tard correspond à deux insertions faites à des dates+heures
différentes.
Ou alors, si date = journée, vous interdisez à un émetteur de faire
deux transactions avec le même destinataire la même journée ? :-)
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.
Larroque writes:
Il doit toujours y avoir une clé primaire dans une table d'une base de
données de SGBD relationnel.
Au sens de la théorie relationnelle, où une table est un ensemble de
t-uples, en effet. Il devrait donc y en avoir. Ca serait bien. Mais
laquelle ?
Si vous prenez comme "date de transaction" la date+heure où
l'insertion a lieu, le renvoi du même contenu de formulaire un peu
plus tard correspond à deux insertions faites à des dates+heures
différentes.
Ou alors, si date = journée, vous interdisez à un émetteur de faire
deux transactions avec le même destinataire la même journée ? :-)
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.
Si, obligation il y a.
N'importe quel ouvrage sur les bases de données relationnelles ( comme
ceux de M. Gardarin ) vous le confirmera.
Date est un objet que vous pouvez définir à la nano-seconde si ça vous
chante et si votre système de traitement le permet.
De toute façon, si vous créez des tables sans clé, c'est qu'il y a eu
erreur d'analyse
En ce qui concerne l'implémentation, M. Gallet, dans sa documentation,
donne la réponse:
- l'auto-incrément, même défini en tant que clé primaire dans la base de
données, n'est en aucun cas ( à moins que ce champ ne corresponde à la
modélisation d'un objet du monde réel ) la vrai clé;
- d'où la nécessité, dans ce cas, de définir la vrai clé primaire en
indiquant la clause UNIQUE(.....) et d'utiliser, dans le cas de Mysql,
le moteur InnoDb.
Si, obligation il y a.
N'importe quel ouvrage sur les bases de données relationnelles ( comme
ceux de M. Gardarin ) vous le confirmera.
Date est un objet que vous pouvez définir à la nano-seconde si ça vous
chante et si votre système de traitement le permet.
De toute façon, si vous créez des tables sans clé, c'est qu'il y a eu
erreur d'analyse
En ce qui concerne l'implémentation, M. Gallet, dans sa documentation,
donne la réponse:
- l'auto-incrément, même défini en tant que clé primaire dans la base de
données, n'est en aucun cas ( à moins que ce champ ne corresponde à la
modélisation d'un objet du monde réel ) la vrai clé;
- d'où la nécessité, dans ce cas, de définir la vrai clé primaire en
indiquant la clause UNIQUE(.....) et d'utiliser, dans le cas de Mysql,
le moteur InnoDb.
Si, obligation il y a.
N'importe quel ouvrage sur les bases de données relationnelles ( comme
ceux de M. Gardarin ) vous le confirmera.
Date est un objet que vous pouvez définir à la nano-seconde si ça vous
chante et si votre système de traitement le permet.
De toute façon, si vous créez des tables sans clé, c'est qu'il y a eu
erreur d'analyse
En ce qui concerne l'implémentation, M. Gallet, dans sa documentation,
donne la réponse:
- l'auto-incrément, même défini en tant que clé primaire dans la base de
données, n'est en aucun cas ( à moins que ce champ ne corresponde à la
modélisation d'un objet du monde réel ) la vrai clé;
- d'où la nécessité, dans ce cas, de définir la vrai clé primaire en
indiquant la clause UNIQUE(.....) et d'utiliser, dans le cas de Mysql,
le moteur InnoDb.
Si, il y a. Voir les ouvrages de M. Gardarin, par ex, je cite:
"Par définition, une relation est un ensemble de tuples. Un ensemble
n'ayant pas d'élément en double, il ne peut exister 2 fois le même tuple
dans une relation. Afin d'identifier les tuples d'une relation sans
donner toutes les valeurs et d'assurer simplement l'unicité des tuples,
la notion de clé est utilisé.
Clé ( Key ): Ensemble d'attributs minimal dont la connaissance des
valeurs permet d'identifier un tuple unique de la relation considérée.
"
Si, il y a. Voir les ouvrages de M. Gardarin, par ex, je cite:
"Par définition, une relation est un ensemble de tuples. Un ensemble
n'ayant pas d'élément en double, il ne peut exister 2 fois le même tuple
dans une relation. Afin d'identifier les tuples d'une relation sans
donner toutes les valeurs et d'assurer simplement l'unicité des tuples,
la notion de clé est utilisé.
Clé ( Key ): Ensemble d'attributs minimal dont la connaissance des
valeurs permet d'identifier un tuple unique de la relation considérée.
"
Si, il y a. Voir les ouvrages de M. Gardarin, par ex, je cite:
"Par définition, une relation est un ensemble de tuples. Un ensemble
n'ayant pas d'élément en double, il ne peut exister 2 fois le même tuple
dans une relation. Afin d'identifier les tuples d'une relation sans
donner toutes les valeurs et d'assurer simplement l'unicité des tuples,
la notion de clé est utilisé.
Clé ( Key ): Ensemble d'attributs minimal dont la connaissance des
valeurs permet d'identifier un tuple unique de la relation considérée.
"
Aucune obligation à avoir les données normalisées.
Date est un objet que vous pouvez définir à la nano-seconde si ça vous
chante et si votre système de traitement le permet.
Ca ne fait que diminuer la probabilité de collision, pas l'annuler.
De toute façon, si vous créez des tables sans clé, c'est qu'il y a eu
erreur d'analyse
Non.
Une table n'a pas nécessairement de clef primaire. Ce n'est pas utile
dans tous les cas.
Je vous donne un seul exemple : une table utilisé en append only (que des
insertions, aucune modification), par exemple le stockage de logs d'une
application quelconque. Il n'y a besoin d'aucune clef sur cette table.
En ce qui concerne l'implémentation, M. Gallet, dans sa documentation,
donne la réponse:
- l'auto-incrément, même défini en tant que clé primaire dans la base de
données, n'est en aucun cas ( à moins que ce champ ne corresponde à la
modélisation d'un objet du monde réel ) la vrai clé;
On parle de clef technique vs une clef naturelle. Vraie clef et fausse
clef cela ne veut rien dire.
Par définition le Mysql-ism auto_increment ne peut qu'être une clef
technique.
- d'où la nécessité, dans ce cas, de définir la vrai clé primaire en
indiquant la clause UNIQUE(.....) et d'utiliser, dans le cas de Mysql,
le moteur InnoDb.
Vous êtes au courant qu'il existe
1) autre chose que MySQL dans la vraie vie
2) des objets normalisés pour ce besoin, qu'on appelle les séquences ?
Aucune obligation à avoir les données normalisées.
Date est un objet que vous pouvez définir à la nano-seconde si ça vous
chante et si votre système de traitement le permet.
Ca ne fait que diminuer la probabilité de collision, pas l'annuler.
De toute façon, si vous créez des tables sans clé, c'est qu'il y a eu
erreur d'analyse
Non.
Une table n'a pas nécessairement de clef primaire. Ce n'est pas utile
dans tous les cas.
Je vous donne un seul exemple : une table utilisé en append only (que des
insertions, aucune modification), par exemple le stockage de logs d'une
application quelconque. Il n'y a besoin d'aucune clef sur cette table.
En ce qui concerne l'implémentation, M. Gallet, dans sa documentation,
donne la réponse:
- l'auto-incrément, même défini en tant que clé primaire dans la base de
données, n'est en aucun cas ( à moins que ce champ ne corresponde à la
modélisation d'un objet du monde réel ) la vrai clé;
On parle de clef technique vs une clef naturelle. Vraie clef et fausse
clef cela ne veut rien dire.
Par définition le Mysql-ism auto_increment ne peut qu'être une clef
technique.
- d'où la nécessité, dans ce cas, de définir la vrai clé primaire en
indiquant la clause UNIQUE(.....) et d'utiliser, dans le cas de Mysql,
le moteur InnoDb.
Vous êtes au courant qu'il existe
1) autre chose que MySQL dans la vraie vie
2) des objets normalisés pour ce besoin, qu'on appelle les séquences ?
Aucune obligation à avoir les données normalisées.
Date est un objet que vous pouvez définir à la nano-seconde si ça vous
chante et si votre système de traitement le permet.
Ca ne fait que diminuer la probabilité de collision, pas l'annuler.
De toute façon, si vous créez des tables sans clé, c'est qu'il y a eu
erreur d'analyse
Non.
Une table n'a pas nécessairement de clef primaire. Ce n'est pas utile
dans tous les cas.
Je vous donne un seul exemple : une table utilisé en append only (que des
insertions, aucune modification), par exemple le stockage de logs d'une
application quelconque. Il n'y a besoin d'aucune clef sur cette table.
En ce qui concerne l'implémentation, M. Gallet, dans sa documentation,
donne la réponse:
- l'auto-incrément, même défini en tant que clé primaire dans la base de
données, n'est en aucun cas ( à moins que ce champ ne corresponde à la
modélisation d'un objet du monde réel ) la vrai clé;
On parle de clef technique vs une clef naturelle. Vraie clef et fausse
clef cela ne veut rien dire.
Par définition le Mysql-ism auto_increment ne peut qu'être une clef
technique.
- d'où la nécessité, dans ce cas, de définir la vrai clé primaire en
indiquant la clause UNIQUE(.....) et d'utiliser, dans le cas de Mysql,
le moteur InnoDb.
Vous êtes au courant qu'il existe
1) autre chose que MySQL dans la vraie vie
2) des objets normalisés pour ce besoin, qu'on appelle les séquences ?
Aucune obligation à avoir les données normalisées.
Bien sur qu'il n'y a aucune obligation à suivre des règles; mais s'il y
a des gens qui les ont établies, ce n'est pas pour rien.
Si vous n'avez pas de clé, impossible ( c'est d'ailleurs en partie pour
ça que sont nés les SGBD relationnels )..
Je parle de clé au niveau de la conception. Les clés techniques
n'existent pas, amha ( jamais entendu parlé ).
Maintenant, si vous souhaitez ou si certains auteurs souhaitent les
appeler comme ça, pourquoi pas.
Aucune obligation à avoir les données normalisées.
Bien sur qu'il n'y a aucune obligation à suivre des règles; mais s'il y
a des gens qui les ont établies, ce n'est pas pour rien.
Si vous n'avez pas de clé, impossible ( c'est d'ailleurs en partie pour
ça que sont nés les SGBD relationnels )..
Je parle de clé au niveau de la conception. Les clés techniques
n'existent pas, amha ( jamais entendu parlé ).
Maintenant, si vous souhaitez ou si certains auteurs souhaitent les
appeler comme ça, pourquoi pas.
Aucune obligation à avoir les données normalisées.
Bien sur qu'il n'y a aucune obligation à suivre des règles; mais s'il y
a des gens qui les ont établies, ce n'est pas pour rien.
Si vous n'avez pas de clé, impossible ( c'est d'ailleurs en partie pour
ça que sont nés les SGBD relationnels )..
Je parle de clé au niveau de la conception. Les clés techniques
n'existent pas, amha ( jamais entendu parlé ).
Maintenant, si vous souhaitez ou si certains auteurs souhaitent les
appeler comme ça, pourquoi pas.
