Patrick Mevzek a écrit :Le Mon, 19 Dec 2005 18:14:36 +0100, ftc a écrit :C'est bien pour ça que l'on parlait d'un niveau sémantique donc
conceptuel. A un moment ou un autre, il vous faut bien définir une
clé primaire quelque part dans votre système, que l'implantation soit
faite dans votre SGBDR ou dans votre application cliente, ça ne
change rien au schéma de votre base et au fait qu'il faille une clé
primaire.
Aucune obligation d'avoir des clefs primaires dans toutes les tables.
Non, si vous ne voulez rien faire de ces enregistrements là.
J'aimerais bien savoir comment vous faites pour isoler un enregistrement
si en terme de *conception* vous n'avez pas défini de clé primaire.
Patrick Mevzek a écrit :
Le Mon, 19 Dec 2005 18:14:36 +0100, ftc a écrit :
C'est bien pour ça que l'on parlait d'un niveau sémantique donc
conceptuel. A un moment ou un autre, il vous faut bien définir une
clé primaire quelque part dans votre système, que l'implantation soit
faite dans votre SGBDR ou dans votre application cliente, ça ne
change rien au schéma de votre base et au fait qu'il faille une clé
primaire.
Aucune obligation d'avoir des clefs primaires dans toutes les tables.
Non, si vous ne voulez rien faire de ces enregistrements là.
J'aimerais bien savoir comment vous faites pour isoler un enregistrement
si en terme de *conception* vous n'avez pas défini de clé primaire.
Patrick Mevzek a écrit :Le Mon, 19 Dec 2005 18:14:36 +0100, ftc a écrit :C'est bien pour ça que l'on parlait d'un niveau sémantique donc
conceptuel. A un moment ou un autre, il vous faut bien définir une
clé primaire quelque part dans votre système, que l'implantation soit
faite dans votre SGBDR ou dans votre application cliente, ça ne
change rien au schéma de votre base et au fait qu'il faille une clé
primaire.
Aucune obligation d'avoir des clefs primaires dans toutes les tables.
Non, si vous ne voulez rien faire de ces enregistrements là.
J'aimerais bien savoir comment vous faites pour isoler un enregistrement
si en terme de *conception* vous n'avez pas défini de clé primaire.
J'aimerais bien savoir comment vous faites pour isoler un
enregistrement si en terme de *conception* vous n'avez pas défini de
clé primaire.
Votre remarque est particulièrement idiote.
De nombreuses applications
utilisent des tables sans clef dans lesquelles on trouve aussi bien des
lignes uniques que doublonnées. Et c'est une pratique courrante et
intéresante.
Je ne vous donnerais qu'un seul exemple : les traces !
Dans un site web, il arrive fréquemment que l'on veuille tracer
l'activité d'un internaute. Pour peu qu'il revienne et qu'en parrallèle
s'éxécutent les mêmes activités au même moment on se retrouve avec des
doublons.
Cela permet d'éviter de générer des clefs auto incrémentées qui
nécessite un travail important du serveur donc de la contention, clef
qui d'ailleurs n'auraient aucune utilité, car l'exploitation des traces
à plus un but strictement statistique qu'informationnel.
En d'autres termes il est souhaitable, préférable et performant de
construire des tables sans clefs dans ce cas précis.
J'aimerais bien savoir comment vous faites pour isoler un
enregistrement si en terme de *conception* vous n'avez pas défini de
clé primaire.
Votre remarque est particulièrement idiote.
De nombreuses applications
utilisent des tables sans clef dans lesquelles on trouve aussi bien des
lignes uniques que doublonnées. Et c'est une pratique courrante et
intéresante.
Je ne vous donnerais qu'un seul exemple : les traces !
Dans un site web, il arrive fréquemment que l'on veuille tracer
l'activité d'un internaute. Pour peu qu'il revienne et qu'en parrallèle
s'éxécutent les mêmes activités au même moment on se retrouve avec des
doublons.
Cela permet d'éviter de générer des clefs auto incrémentées qui
nécessite un travail important du serveur donc de la contention, clef
qui d'ailleurs n'auraient aucune utilité, car l'exploitation des traces
à plus un but strictement statistique qu'informationnel.
En d'autres termes il est souhaitable, préférable et performant de
construire des tables sans clefs dans ce cas précis.
J'aimerais bien savoir comment vous faites pour isoler un
enregistrement si en terme de *conception* vous n'avez pas défini de
clé primaire.
Votre remarque est particulièrement idiote.
De nombreuses applications
utilisent des tables sans clef dans lesquelles on trouve aussi bien des
lignes uniques que doublonnées. Et c'est une pratique courrante et
intéresante.
Je ne vous donnerais qu'un seul exemple : les traces !
Dans un site web, il arrive fréquemment que l'on veuille tracer
l'activité d'un internaute. Pour peu qu'il revienne et qu'en parrallèle
s'éxécutent les mêmes activités au même moment on se retrouve avec des
doublons.
Cela permet d'éviter de générer des clefs auto incrémentées qui
nécessite un travail important du serveur donc de la contention, clef
qui d'ailleurs n'auraient aucune utilité, car l'exploitation des traces
à plus un but strictement statistique qu'informationnel.
En d'autres termes il est souhaitable, préférable et performant de
construire des tables sans clefs dans ce cas précis.
Fred Brouard - SQLpro a écrit :J'aimerais bien savoir comment vous faites pour isoler un
enregistrement si en terme de *conception* vous n'avez pas défini de
clé primaire.
Votre remarque est particulièrement idiote.
Je vous remercie.
>De nombreuses applicationsutilisent des tables sans clef dans lesquelles on trouve aussi bien
des lignes uniques que doublonnées. Et c'est une pratique courrante et
intéresante.
Que la pratique soit courante, je veux bien vous croire, qu'elle soit
intéressante est une toute autre chose.
>Je ne vous donnerais qu'un seul exemple : les traces !Dans un site web, il arrive fréquemment que l'on veuille tracer
l'activité d'un internaute. Pour peu qu'il revienne et qu'en
parrallèle s'éxécutent les mêmes activités au même moment on se
retrouve avec des doublons.
Cela permet d'éviter de générer des clefs auto incrémentées qui
nécessite un travail important du serveur donc de la contention, clef
qui d'ailleurs n'auraient aucune utilité, car l'exploitation des
traces à plus un but strictement statistique qu'informationnel.
Pourquoi vouloir générer une clé auto-incrémentée alors que
l'information d'unicité est déjà présente. Vos logs sont d'une part
reliés à un internaute et d'autre part reliés à une notion de temps. Si
vous supprimer l'un ou l'autre, vous perdez une très grande partie de
l'information.
Maintenant que vous vouliez faire une table de trace sans notion de
temps me semble être une erreur de conception car vous perdez une grande
partie des possibilité de votre système comme de faire une trace type du
parcours du visiteur ( graphe des pages et temps moyen de consultation
par exemple ).
Même dans les logiciels de statistiques, on utilise la notion d'unicité
d'un enregistrement.
Je pratique les SGBDR depuis quelques temps déjà
et je n'ai rencontré de
cas ou des enregistrements devaient être doublonnés dans une table de
SGBDR que pour faire du data mining ou les données proviennent d'un
ensemble hétérogène de sources ( fichiers texte, SGBD divers, système de
log ... ). Le premier travail consite d'ailleurs en un dédoublonnage.
Mais dans ce cas, le manque d'unicité d'un enregistrement fait perdre
déjà beaucoup ( trop ) d'informations et le SGBDR n'est là que pour
faire du stockage et non de l'analyse, on l'utilise donc un peu contre
nature.En d'autres termes il est souhaitable, préférable et performant de
construire des tables sans clefs dans ce cas précis.
On va virer le souhaitable et le préférable et garder le performant ( en
termes de ressources ) si vous permettez. Cette performance étant toute
relative puisqu'elle n'intervient que lors de l'insertion et non de la
consultation.
Si c'est pour avoir une liste de lignes doublonnées, je dirais qu'il est
souhaitable, préférable et performant d'utiliser des fichiers log ou un
SGBD non relationnel.
Bien loin de moi l'idée de vouloir faire de l'*intégrisme* du modèle
relationnel, bien au contraire, je conseillerai même bien souvent de ne
pas utiliser un SGBDR mais un outil plus adapté. Le problèmes est que
nous sommes entré dans un ère ou dès qu'une application recquiert du
stockage, on fait appel à un SGBDR quite à utiliser cet outil n'importe
comment.
L'*intégriste* est celui qui dit que son produit est le meilleur et
adapté en toutes circonstances.
Fred Brouard - SQLpro a écrit :
J'aimerais bien savoir comment vous faites pour isoler un
enregistrement si en terme de *conception* vous n'avez pas défini de
clé primaire.
Votre remarque est particulièrement idiote.
Je vous remercie.
>De nombreuses applications
utilisent des tables sans clef dans lesquelles on trouve aussi bien
des lignes uniques que doublonnées. Et c'est une pratique courrante et
intéresante.
Que la pratique soit courante, je veux bien vous croire, qu'elle soit
intéressante est une toute autre chose.
>Je ne vous donnerais qu'un seul exemple : les traces !
Dans un site web, il arrive fréquemment que l'on veuille tracer
l'activité d'un internaute. Pour peu qu'il revienne et qu'en
parrallèle s'éxécutent les mêmes activités au même moment on se
retrouve avec des doublons.
Cela permet d'éviter de générer des clefs auto incrémentées qui
nécessite un travail important du serveur donc de la contention, clef
qui d'ailleurs n'auraient aucune utilité, car l'exploitation des
traces à plus un but strictement statistique qu'informationnel.
Pourquoi vouloir générer une clé auto-incrémentée alors que
l'information d'unicité est déjà présente. Vos logs sont d'une part
reliés à un internaute et d'autre part reliés à une notion de temps. Si
vous supprimer l'un ou l'autre, vous perdez une très grande partie de
l'information.
Maintenant que vous vouliez faire une table de trace sans notion de
temps me semble être une erreur de conception car vous perdez une grande
partie des possibilité de votre système comme de faire une trace type du
parcours du visiteur ( graphe des pages et temps moyen de consultation
par exemple ).
Même dans les logiciels de statistiques, on utilise la notion d'unicité
d'un enregistrement.
Je pratique les SGBDR depuis quelques temps déjà
et je n'ai rencontré de
cas ou des enregistrements devaient être doublonnés dans une table de
SGBDR que pour faire du data mining ou les données proviennent d'un
ensemble hétérogène de sources ( fichiers texte, SGBD divers, système de
log ... ). Le premier travail consite d'ailleurs en un dédoublonnage.
Mais dans ce cas, le manque d'unicité d'un enregistrement fait perdre
déjà beaucoup ( trop ) d'informations et le SGBDR n'est là que pour
faire du stockage et non de l'analyse, on l'utilise donc un peu contre
nature.
En d'autres termes il est souhaitable, préférable et performant de
construire des tables sans clefs dans ce cas précis.
On va virer le souhaitable et le préférable et garder le performant ( en
termes de ressources ) si vous permettez. Cette performance étant toute
relative puisqu'elle n'intervient que lors de l'insertion et non de la
consultation.
Si c'est pour avoir une liste de lignes doublonnées, je dirais qu'il est
souhaitable, préférable et performant d'utiliser des fichiers log ou un
SGBD non relationnel.
Bien loin de moi l'idée de vouloir faire de l'*intégrisme* du modèle
relationnel, bien au contraire, je conseillerai même bien souvent de ne
pas utiliser un SGBDR mais un outil plus adapté. Le problèmes est que
nous sommes entré dans un ère ou dès qu'une application recquiert du
stockage, on fait appel à un SGBDR quite à utiliser cet outil n'importe
comment.
L'*intégriste* est celui qui dit que son produit est le meilleur et
adapté en toutes circonstances.
Fred Brouard - SQLpro a écrit :J'aimerais bien savoir comment vous faites pour isoler un
enregistrement si en terme de *conception* vous n'avez pas défini de
clé primaire.
Votre remarque est particulièrement idiote.
Je vous remercie.
>De nombreuses applicationsutilisent des tables sans clef dans lesquelles on trouve aussi bien
des lignes uniques que doublonnées. Et c'est une pratique courrante et
intéresante.
Que la pratique soit courante, je veux bien vous croire, qu'elle soit
intéressante est une toute autre chose.
>Je ne vous donnerais qu'un seul exemple : les traces !Dans un site web, il arrive fréquemment que l'on veuille tracer
l'activité d'un internaute. Pour peu qu'il revienne et qu'en
parrallèle s'éxécutent les mêmes activités au même moment on se
retrouve avec des doublons.
Cela permet d'éviter de générer des clefs auto incrémentées qui
nécessite un travail important du serveur donc de la contention, clef
qui d'ailleurs n'auraient aucune utilité, car l'exploitation des
traces à plus un but strictement statistique qu'informationnel.
Pourquoi vouloir générer une clé auto-incrémentée alors que
l'information d'unicité est déjà présente. Vos logs sont d'une part
reliés à un internaute et d'autre part reliés à une notion de temps. Si
vous supprimer l'un ou l'autre, vous perdez une très grande partie de
l'information.
Maintenant que vous vouliez faire une table de trace sans notion de
temps me semble être une erreur de conception car vous perdez une grande
partie des possibilité de votre système comme de faire une trace type du
parcours du visiteur ( graphe des pages et temps moyen de consultation
par exemple ).
Même dans les logiciels de statistiques, on utilise la notion d'unicité
d'un enregistrement.
Je pratique les SGBDR depuis quelques temps déjà
et je n'ai rencontré de
cas ou des enregistrements devaient être doublonnés dans une table de
SGBDR que pour faire du data mining ou les données proviennent d'un
ensemble hétérogène de sources ( fichiers texte, SGBD divers, système de
log ... ). Le premier travail consite d'ailleurs en un dédoublonnage.
Mais dans ce cas, le manque d'unicité d'un enregistrement fait perdre
déjà beaucoup ( trop ) d'informations et le SGBDR n'est là que pour
faire du stockage et non de l'analyse, on l'utilise donc un peu contre
nature.En d'autres termes il est souhaitable, préférable et performant de
construire des tables sans clefs dans ce cas précis.
On va virer le souhaitable et le préférable et garder le performant ( en
termes de ressources ) si vous permettez. Cette performance étant toute
relative puisqu'elle n'intervient que lors de l'insertion et non de la
consultation.
Si c'est pour avoir une liste de lignes doublonnées, je dirais qu'il est
souhaitable, préférable et performant d'utiliser des fichiers log ou un
SGBD non relationnel.
Bien loin de moi l'idée de vouloir faire de l'*intégrisme* du modèle
relationnel, bien au contraire, je conseillerai même bien souvent de ne
pas utiliser un SGBDR mais un outil plus adapté. Le problèmes est que
nous sommes entré dans un ère ou dès qu'une application recquiert du
stockage, on fait appel à un SGBDR quite à utiliser cet outil n'importe
comment.
L'*intégriste* est celui qui dit que son produit est le meilleur et
adapté en toutes circonstances.
Vous n'avez visiblement jamais travaillé avec de grandes masses
d'information. La limite actuelle de précision des horodatage est de
quelques millisecondes. D'ou de fréquent doublons pour des bases de
données fortement solicités.
Vivez dans un monde réel pas celui des cours magistraux et de la pure
théorie !!!
Je pratique les SGBDR depuis quelques temps déjà
moi seulement depuis seulement 1986
Si c'est pour avoir une liste de lignes doublonnées, je dirais qu'il
est souhaitable, préférable et performant d'utiliser des fichiers log
ou un SGBD non relationnel.
et re retraiter tout cela dans un SGBDR.... quel temps perdu en I/O !
Ne révez pas, travaillez. Vous êtes visiblement un peu jeune dans ce
métier !
Vous n'avez visiblement jamais travaillé avec de grandes masses
d'information. La limite actuelle de précision des horodatage est de
quelques millisecondes. D'ou de fréquent doublons pour des bases de
données fortement solicités.
Vivez dans un monde réel pas celui des cours magistraux et de la pure
théorie !!!
Je pratique les SGBDR depuis quelques temps déjà
moi seulement depuis seulement 1986
Si c'est pour avoir une liste de lignes doublonnées, je dirais qu'il
est souhaitable, préférable et performant d'utiliser des fichiers log
ou un SGBD non relationnel.
et re retraiter tout cela dans un SGBDR.... quel temps perdu en I/O !
Ne révez pas, travaillez. Vous êtes visiblement un peu jeune dans ce
métier !
Vous n'avez visiblement jamais travaillé avec de grandes masses
d'information. La limite actuelle de précision des horodatage est de
quelques millisecondes. D'ou de fréquent doublons pour des bases de
données fortement solicités.
Vivez dans un monde réel pas celui des cours magistraux et de la pure
théorie !!!
Je pratique les SGBDR depuis quelques temps déjà
moi seulement depuis seulement 1986
Si c'est pour avoir une liste de lignes doublonnées, je dirais qu'il
est souhaitable, préférable et performant d'utiliser des fichiers log
ou un SGBD non relationnel.
et re retraiter tout cela dans un SGBDR.... quel temps perdu en I/O !
Ne révez pas, travaillez. Vous êtes visiblement un peu jeune dans ce
métier !
PRIMARY et INDEX sont deux concepts très différents.
c'est vrai... mais concrètement, la contrainte d'unicité inhérente à
la clé primaire est implémentée par un index.
Concrétement dans certains SGBDR ! pas dans tous les cas. Par exemple
dans le cas de séquenceurs fermés pas besoin d'index pour générer
l'unicité.
PRIMARY et INDEX sont deux concepts très différents.
c'est vrai... mais concrètement, la contrainte d'unicité inhérente à
la clé primaire est implémentée par un index.
Concrétement dans certains SGBDR ! pas dans tous les cas. Par exemple
dans le cas de séquenceurs fermés pas besoin d'index pour générer
l'unicité.
PRIMARY et INDEX sont deux concepts très différents.
c'est vrai... mais concrètement, la contrainte d'unicité inhérente à
la clé primaire est implémentée par un index.
Concrétement dans certains SGBDR ! pas dans tous les cas. Par exemple
dans le cas de séquenceurs fermés pas besoin d'index pour générer
l'unicité.
