helios a écrit :en SQL toute la base est impacté par le changement (donc arret
exploitation) tandis que un MV seul le champ 150 des enregistrements
concerné le sont (donc exploitation non arreté)
Oui mais non, c'est plus un problème de conception de la base (il faut
la prévoir suffisament ouverte, et mettre des points d'entrée sous forme
de procédure stockée par exemple) et de travail de DBA que de
supériorité de l'un ou l'autre système.
D'après ce que comprends, j'aurai tendance à dire que le SQL impose de
structurer la démarche d'évolution, alors que le MV permet de mettre des
rustines sur la base (ne pas considérer le terme "rustine" comme
péjoratif, je ne veux pas entrer dans le débat "c'est mieux", juste
comprendre). Ceci dit, dans les deux cas, il est indispensable de mettre
à jour le programme pour refleter les modifications au niveau de
l'utilisateur).
Au fait, dans les systèmes MV, comment accède t on aux données en dehors
du client intégré (comprendre : ligne de commande)?
gg
helios a écrit :
en SQL toute la base est impacté par le changement (donc arret
exploitation) tandis que un MV seul le champ 150 des enregistrements
concerné le sont (donc exploitation non arreté)
Oui mais non, c'est plus un problème de conception de la base (il faut
la prévoir suffisament ouverte, et mettre des points d'entrée sous forme
de procédure stockée par exemple) et de travail de DBA que de
supériorité de l'un ou l'autre système.
D'après ce que comprends, j'aurai tendance à dire que le SQL impose de
structurer la démarche d'évolution, alors que le MV permet de mettre des
rustines sur la base (ne pas considérer le terme "rustine" comme
péjoratif, je ne veux pas entrer dans le débat "c'est mieux", juste
comprendre). Ceci dit, dans les deux cas, il est indispensable de mettre
à jour le programme pour refleter les modifications au niveau de
l'utilisateur).
Au fait, dans les systèmes MV, comment accède t on aux données en dehors
du client intégré (comprendre : ligne de commande)?
gg
helios a écrit :en SQL toute la base est impacté par le changement (donc arret
exploitation) tandis que un MV seul le champ 150 des enregistrements
concerné le sont (donc exploitation non arreté)
Oui mais non, c'est plus un problème de conception de la base (il faut
la prévoir suffisament ouverte, et mettre des points d'entrée sous forme
de procédure stockée par exemple) et de travail de DBA que de
supériorité de l'un ou l'autre système.
D'après ce que comprends, j'aurai tendance à dire que le SQL impose de
structurer la démarche d'évolution, alors que le MV permet de mettre des
rustines sur la base (ne pas considérer le terme "rustine" comme
péjoratif, je ne veux pas entrer dans le débat "c'est mieux", juste
comprendre). Ceci dit, dans les deux cas, il est indispensable de mettre
à jour le programme pour refleter les modifications au niveau de
l'utilisateur).
Au fait, dans les systèmes MV, comment accède t on aux données en dehors
du client intégré (comprendre : ligne de commande)?
gg
helios a écrit :en SQL toute la base est impacté par le changement (donc arret
exploitation) tandis que un MV seul le champ 150 des enregistrements
concerné le sont (donc exploitation non arreté)
Oui mais non, c'est plus un problème de conception de la base (il faut
la prévoir suffisament ouverte, et mettre des points d'entrée sous forme
de procédure stockée par exemple) et de travail de DBA que de
supériorité de l'un ou l'autre système.
D'après ce que comprends, j'aurai tendance à dire que le SQL impose de
structurer la démarche d'évolution, alors que le MV permet de mettre des
rustines sur la base (ne pas considérer le terme "rustine" comme
péjoratif, je ne veux pas entrer dans le débat "c'est mieux", juste
comprendre). Ceci dit, dans les deux cas, il est indispensable de mettre
à jour le programme pour refleter les modifications au niveau de
l'utilisateur).
Au fait, dans les systèmes MV, comment accède t on aux données en dehors
du client intégré (comprendre : ligne de commande)?
gg
helios a écrit :
en SQL toute la base est impacté par le changement (donc arret
exploitation) tandis que un MV seul le champ 150 des enregistrements
concerné le sont (donc exploitation non arreté)
Oui mais non, c'est plus un problème de conception de la base (il faut
la prévoir suffisament ouverte, et mettre des points d'entrée sous forme
de procédure stockée par exemple) et de travail de DBA que de
supériorité de l'un ou l'autre système.
D'après ce que comprends, j'aurai tendance à dire que le SQL impose de
structurer la démarche d'évolution, alors que le MV permet de mettre des
rustines sur la base (ne pas considérer le terme "rustine" comme
péjoratif, je ne veux pas entrer dans le débat "c'est mieux", juste
comprendre). Ceci dit, dans les deux cas, il est indispensable de mettre
à jour le programme pour refleter les modifications au niveau de
l'utilisateur).
Au fait, dans les systèmes MV, comment accède t on aux données en dehors
du client intégré (comprendre : ligne de commande)?
gg
helios a écrit :en SQL toute la base est impacté par le changement (donc arret
exploitation) tandis que un MV seul le champ 150 des enregistrements
concerné le sont (donc exploitation non arreté)
Oui mais non, c'est plus un problème de conception de la base (il faut
la prévoir suffisament ouverte, et mettre des points d'entrée sous forme
de procédure stockée par exemple) et de travail de DBA que de
supériorité de l'un ou l'autre système.
D'après ce que comprends, j'aurai tendance à dire que le SQL impose de
structurer la démarche d'évolution, alors que le MV permet de mettre des
rustines sur la base (ne pas considérer le terme "rustine" comme
péjoratif, je ne veux pas entrer dans le débat "c'est mieux", juste
comprendre). Ceci dit, dans les deux cas, il est indispensable de mettre
à jour le programme pour refleter les modifications au niveau de
l'utilisateur).
Au fait, dans les systèmes MV, comment accède t on aux données en dehors
du client intégré (comprendre : ligne de commande)?
gg
helios a écrit :je reformules
les champs ne sont pas des enregistrements
un fichiers de 8000 champs a des enregistrements de 8000 champs
en SQL un enregistrement se nomme ligne
en SQL un champ se nomme colonne
en SQL une valeur est une valeur
en SQL une valeur multivalué est une jointure avec une table
en SQL une sous-valeur est la valeur de la table jointe
en SQL une sous-valeur multivalué est une jointure avec une table qui
est dans une table jointe
en SQL une sous-sous-valeur est le la valeur qui est dans la table de
la jointe à la table jointe
en sql une sous-sous-valeur multivalué est la jointure ......
donc un SGBDRMV peut gerer une table SQL puisque dans ce cas il se
limite à table,enregistrement,colonne,valeur jointure puisque SQL ne
sait pas gerer le reste
Ca revient à faire ça (je cherche à comprendre la différence)?
http://www.gg-s.net/helios2.png
gg
helios a écrit :
je reformules
les champs ne sont pas des enregistrements
un fichiers de 8000 champs a des enregistrements de 8000 champs
en SQL un enregistrement se nomme ligne
en SQL un champ se nomme colonne
en SQL une valeur est une valeur
en SQL une valeur multivalué est une jointure avec une table
en SQL une sous-valeur est la valeur de la table jointe
en SQL une sous-valeur multivalué est une jointure avec une table qui
est dans une table jointe
en SQL une sous-sous-valeur est le la valeur qui est dans la table de
la jointe à la table jointe
en sql une sous-sous-valeur multivalué est la jointure ......
donc un SGBDRMV peut gerer une table SQL puisque dans ce cas il se
limite à table,enregistrement,colonne,valeur jointure puisque SQL ne
sait pas gerer le reste
Ca revient à faire ça (je cherche à comprendre la différence)?
http://www.gg-s.net/helios2.png
gg
helios a écrit :je reformules
les champs ne sont pas des enregistrements
un fichiers de 8000 champs a des enregistrements de 8000 champs
en SQL un enregistrement se nomme ligne
en SQL un champ se nomme colonne
en SQL une valeur est une valeur
en SQL une valeur multivalué est une jointure avec une table
en SQL une sous-valeur est la valeur de la table jointe
en SQL une sous-valeur multivalué est une jointure avec une table qui
est dans une table jointe
en SQL une sous-sous-valeur est le la valeur qui est dans la table de
la jointe à la table jointe
en sql une sous-sous-valeur multivalué est la jointure ......
donc un SGBDRMV peut gerer une table SQL puisque dans ce cas il se
limite à table,enregistrement,colonne,valeur jointure puisque SQL ne
sait pas gerer le reste
Ca revient à faire ça (je cherche à comprendre la différence)?
http://www.gg-s.net/helios2.png
gg
oui et tu as eux besoin de 7 tables et 6 jointures alors que pour la
meme chose MV a une table et aucune jointure
et cela juste pour 2 champs multivalué a 2 niveaux alors imagine une
base ou il y a 1000 champs par enregistrement et qu'il y a 6 niveaux par
exemple
oui et tu as eux besoin de 7 tables et 6 jointures alors que pour la
meme chose MV a une table et aucune jointure
et cela juste pour 2 champs multivalué a 2 niveaux alors imagine une
base ou il y a 1000 champs par enregistrement et qu'il y a 6 niveaux par
exemple
oui et tu as eux besoin de 7 tables et 6 jointures alors que pour la
meme chose MV a une table et aucune jointure
et cela juste pour 2 champs multivalué a 2 niveaux alors imagine une
base ou il y a 1000 champs par enregistrement et qu'il y a 6 niveaux par
exemple
on est sur internet pas dans zoologie :-)
en informatique, un processus est une tâche en train de s'exécuter. On
appelle processus l'image de l'état du processeur et de la mémoire au
cours de l'exécution d'un programme.
une jointure une jointure
Ah dans ce cas vous pouvez la définir, non ?
En gestion de base de données relationnelle, une jointure est un lien
combinant les enregistrements de deux tables disposant de valeurs
correspondantes dans un champ commun.
en informatique, un processus est une tâche en train de s'exécuter. On
appelle processus l'image de l'état du processeur et de la mémoire au
cours de l'exécution d'un programme.
Je peux vous montrer ce qu'est un processus unix :
je le peut aussi mais qui t'a parler de processus UNIX ont est dans les
SGBD donc je parle de processus de SGBR sinon pourquoi ne pas parler de
processus anatomique
Et quand un processus (un script php par exemple) veut communiquer une
requête au sgbd (un postgresql) et recevoir un résultat, il utilise un
mécanisme IPC. Comme les autres, et comme peut-être les processus coyote
et openqm auquels vous garantissez un "accès direct sans sale couche".si tu confonds SGBD et DOS ce n'est pas ma faute
DOS ? je n'en ai jamais parlé. Vous confondez DOS et UNIX. C'est pas ma
faute, j'ai mis des liens pourtant.
UNIX est un DOS mais un ignorant ne voit que MSDOS comme DOS
http://fr.wikipedia.org/wiki/DOS
si tu confonds couches DOS et couches applicatives ce n'est pas ma faute
Maintenant on est fixé : un OS pour vous, c'est DOS. On comprend mieux
votre inculture du multiprocessus et parfaitement votre ignorance des
IPC.
Vous confondez persistance et présentation.
oui un OS est un DOS et ton inculture est évidente
pour info je suis Administrateur PICK depuis 1985 Administrateur MOS
depuis 1987 administrateur UNIX depuis 1997 et j'ai deja utilisé aussi
CPM86 et prologue ainsi que DPS6 DPS7 DPS8 sans parler des divers
compatible MSDOS (msdos,opendos,freedos ......) et divers unix
on est sur internet pas dans zoologie :-)
en informatique, un processus est une tâche en train de s'exécuter. On
appelle processus l'image de l'état du processeur et de la mémoire au
cours de l'exécution d'un programme.
une jointure une jointure
Ah dans ce cas vous pouvez la définir, non ?
En gestion de base de données relationnelle, une jointure est un lien
combinant les enregistrements de deux tables disposant de valeurs
correspondantes dans un champ commun.
en informatique, un processus est une tâche en train de s'exécuter. On
appelle processus l'image de l'état du processeur et de la mémoire au
cours de l'exécution d'un programme.
Je peux vous montrer ce qu'est un processus unix :
je le peut aussi mais qui t'a parler de processus UNIX ont est dans les
SGBD donc je parle de processus de SGBR sinon pourquoi ne pas parler de
processus anatomique
Et quand un processus (un script php par exemple) veut communiquer une
requête au sgbd (un postgresql) et recevoir un résultat, il utilise un
mécanisme IPC. Comme les autres, et comme peut-être les processus coyote
et openqm auquels vous garantissez un "accès direct sans sale couche".
si tu confonds SGBD et DOS ce n'est pas ma faute
DOS ? je n'en ai jamais parlé. Vous confondez DOS et UNIX. C'est pas ma
faute, j'ai mis des liens pourtant.
UNIX est un DOS mais un ignorant ne voit que MSDOS comme DOS
http://fr.wikipedia.org/wiki/DOS
si tu confonds couches DOS et couches applicatives ce n'est pas ma faute
Maintenant on est fixé : un OS pour vous, c'est DOS. On comprend mieux
votre inculture du multiprocessus et parfaitement votre ignorance des
IPC.
Vous confondez persistance et présentation.
oui un OS est un DOS et ton inculture est évidente
pour info je suis Administrateur PICK depuis 1985 Administrateur MOS
depuis 1987 administrateur UNIX depuis 1997 et j'ai deja utilisé aussi
CPM86 et prologue ainsi que DPS6 DPS7 DPS8 sans parler des divers
compatible MSDOS (msdos,opendos,freedos ......) et divers unix
on est sur internet pas dans zoologie :-)
en informatique, un processus est une tâche en train de s'exécuter. On
appelle processus l'image de l'état du processeur et de la mémoire au
cours de l'exécution d'un programme.
une jointure une jointure
Ah dans ce cas vous pouvez la définir, non ?
En gestion de base de données relationnelle, une jointure est un lien
combinant les enregistrements de deux tables disposant de valeurs
correspondantes dans un champ commun.
en informatique, un processus est une tâche en train de s'exécuter. On
appelle processus l'image de l'état du processeur et de la mémoire au
cours de l'exécution d'un programme.
Je peux vous montrer ce qu'est un processus unix :
je le peut aussi mais qui t'a parler de processus UNIX ont est dans les
SGBD donc je parle de processus de SGBR sinon pourquoi ne pas parler de
processus anatomique
Et quand un processus (un script php par exemple) veut communiquer une
requête au sgbd (un postgresql) et recevoir un résultat, il utilise un
mécanisme IPC. Comme les autres, et comme peut-être les processus coyote
et openqm auquels vous garantissez un "accès direct sans sale couche".si tu confonds SGBD et DOS ce n'est pas ma faute
DOS ? je n'en ai jamais parlé. Vous confondez DOS et UNIX. C'est pas ma
faute, j'ai mis des liens pourtant.
UNIX est un DOS mais un ignorant ne voit que MSDOS comme DOS
http://fr.wikipedia.org/wiki/DOS
si tu confonds couches DOS et couches applicatives ce n'est pas ma faute
Maintenant on est fixé : un OS pour vous, c'est DOS. On comprend mieux
votre inculture du multiprocessus et parfaitement votre ignorance des
IPC.
Vous confondez persistance et présentation.
oui un OS est un DOS et ton inculture est évidente
pour info je suis Administrateur PICK depuis 1985 Administrateur MOS
depuis 1987 administrateur UNIX depuis 1997 et j'ai deja utilisé aussi
CPM86 et prologue ainsi que DPS6 DPS7 DPS8 sans parler des divers
compatible MSDOS (msdos,opendos,freedos ......) et divers unix
les SGBDRMV peuvent acceder au données par le DATABASIC , PROC et TCL
mais ont peut aussi utilisé des logiciels exterieur tel python, perl ,
ultraedit ....... ou des exterieurs plus specifiques tel winnix,
wintergrate, accuterm, staremul
les SGBDRMV peuvent acceder au données par le DATABASIC , PROC et TCL
mais ont peut aussi utilisé des logiciels exterieur tel python, perl ,
ultraedit ....... ou des exterieurs plus specifiques tel winnix,
wintergrate, accuterm, staremul
les SGBDRMV peuvent acceder au données par le DATABASIC , PROC et TCL
mais ont peut aussi utilisé des logiciels exterieur tel python, perl ,
ultraedit ....... ou des exterieurs plus specifiques tel winnix,
wintergrate, accuterm, staremul
ALain Montfranc a écrit :helios a écritc'est un champ qui contient des valeurs multiples par exemples les prénoms
, ou les numéros de téléphone ou toute information ayant plusieurs
occurrences
Dans ton exemple date_acte / notaire sont multivalués ?
Comment se fait la jonction date <=> notaire ? On suppose que date[0] est
associé à notaire[0] et ainsi de suite ?
par pédagogie je simplie la notation sans la suite
date_acte [1] correspond a notaire [1]
date_acte [2] correspond a notaire [2]
mais si il y a plusieurs date pour le notaire3
date_acte [3,1] correspond a notaire [3]
date_acte [3,2] correspond a notaire [3]
ALain Montfranc a écrit :
helios a écrit
c'est un champ qui contient des valeurs multiples par exemples les prénoms
, ou les numéros de téléphone ou toute information ayant plusieurs
occurrences
Dans ton exemple date_acte / notaire sont multivalués ?
Comment se fait la jonction date <=> notaire ? On suppose que date[0] est
associé à notaire[0] et ainsi de suite ?
par pédagogie je simplie la notation sans la suite
date_acte [1] correspond a notaire [1]
date_acte [2] correspond a notaire [2]
mais si il y a plusieurs date pour le notaire3
date_acte [3,1] correspond a notaire [3]
date_acte [3,2] correspond a notaire [3]
ALain Montfranc a écrit :helios a écritc'est un champ qui contient des valeurs multiples par exemples les prénoms
, ou les numéros de téléphone ou toute information ayant plusieurs
occurrences
Dans ton exemple date_acte / notaire sont multivalués ?
Comment se fait la jonction date <=> notaire ? On suppose que date[0] est
associé à notaire[0] et ainsi de suite ?
par pédagogie je simplie la notation sans la suite
date_acte [1] correspond a notaire [1]
date_acte [2] correspond a notaire [2]
mais si il y a plusieurs date pour le notaire3
date_acte [3,1] correspond a notaire [3]
date_acte [3,2] correspond a notaire [3]
helios a écrit :les SGBDRMV peuvent acceder au données par le DATABASIC , PROC et TCL
mais ont peut aussi utilisé des logiciels exterieur tel python, perl ,
ultraedit ....... ou des exterieurs plus specifiques tel winnix,
wintergrate, accuterm, staremul
OK, mais quid des interfaces "à la windows" ? Je crois comprendre que
les exemples que tu cites sont plustot orientés "interface texte"
(encore une fois, ne pas comprendre le terme "texte" comme péjoratif, je
voudrai que l'on fasse un tour du proprietaire et que les debats
inutiles cessent, ca fait perdre du temps a tout le monde). j'ai compris
les idées que tu essaye de véhiculer dans l'autre partie du thread (les
quelques schemas), je voudrai maintenant (et je ne pense pas etre le
seul) voire ce que ca peut donner du coté "utilisateur".
Si je fais une interface "à la windows", il faudra surement que je
modifie cette partie si j'applique une modification structurelle à la
base ou bien est ce que les tableaux de resultats sont uniquement
dynamiques (du point de vue des données). Comment va se présenter un
champ multivalué sur une interface graphique ?
Peux tu, s'il te plait, nous donner un lien sur une/des application(s)
qui utilise le MV, mais quelque chose dont on puisse se faire une idée
(=pas de référence au système des gestion des lignes téléphoniques ou au
système des gestion du cadastre d'une ville)?
gg
helios a écrit :
les SGBDRMV peuvent acceder au données par le DATABASIC , PROC et TCL
mais ont peut aussi utilisé des logiciels exterieur tel python, perl ,
ultraedit ....... ou des exterieurs plus specifiques tel winnix,
wintergrate, accuterm, staremul
OK, mais quid des interfaces "à la windows" ? Je crois comprendre que
les exemples que tu cites sont plustot orientés "interface texte"
(encore une fois, ne pas comprendre le terme "texte" comme péjoratif, je
voudrai que l'on fasse un tour du proprietaire et que les debats
inutiles cessent, ca fait perdre du temps a tout le monde). j'ai compris
les idées que tu essaye de véhiculer dans l'autre partie du thread (les
quelques schemas), je voudrai maintenant (et je ne pense pas etre le
seul) voire ce que ca peut donner du coté "utilisateur".
Si je fais une interface "à la windows", il faudra surement que je
modifie cette partie si j'applique une modification structurelle à la
base ou bien est ce que les tableaux de resultats sont uniquement
dynamiques (du point de vue des données). Comment va se présenter un
champ multivalué sur une interface graphique ?
Peux tu, s'il te plait, nous donner un lien sur une/des application(s)
qui utilise le MV, mais quelque chose dont on puisse se faire une idée
(=pas de référence au système des gestion des lignes téléphoniques ou au
système des gestion du cadastre d'une ville)?
gg
helios a écrit :les SGBDRMV peuvent acceder au données par le DATABASIC , PROC et TCL
mais ont peut aussi utilisé des logiciels exterieur tel python, perl ,
ultraedit ....... ou des exterieurs plus specifiques tel winnix,
wintergrate, accuterm, staremul
OK, mais quid des interfaces "à la windows" ? Je crois comprendre que
les exemples que tu cites sont plustot orientés "interface texte"
(encore une fois, ne pas comprendre le terme "texte" comme péjoratif, je
voudrai que l'on fasse un tour du proprietaire et que les debats
inutiles cessent, ca fait perdre du temps a tout le monde). j'ai compris
les idées que tu essaye de véhiculer dans l'autre partie du thread (les
quelques schemas), je voudrai maintenant (et je ne pense pas etre le
seul) voire ce que ca peut donner du coté "utilisateur".
Si je fais une interface "à la windows", il faudra surement que je
modifie cette partie si j'applique une modification structurelle à la
base ou bien est ce que les tableaux de resultats sont uniquement
dynamiques (du point de vue des données). Comment va se présenter un
champ multivalué sur une interface graphique ?
Peux tu, s'il te plait, nous donner un lien sur une/des application(s)
qui utilise le MV, mais quelque chose dont on puisse se faire une idée
(=pas de référence au système des gestion des lignes téléphoniques ou au
système des gestion du cadastre d'une ville)?
gg
oui et tu as eux besoin de 7 tables et 6 jointures alors que pour la
meme chose MV a une table et aucune jointure
et cela juste pour 2 champs multivalué a 2 niveaux alors imagine une
base ou il y a 1000 champs par enregistrement et qu'il y a 6 niveaux
par exemple
Ok, j'ai maintenant compris le concept, je trouve qu'il est domage que
cette discussion n'ait pas eu lieu plus tot, ca aurait evité, je pense,
pas mal de paroles "mal placées"...
gg
oui et tu as eux besoin de 7 tables et 6 jointures alors que pour la
meme chose MV a une table et aucune jointure
et cela juste pour 2 champs multivalué a 2 niveaux alors imagine une
base ou il y a 1000 champs par enregistrement et qu'il y a 6 niveaux
par exemple
Ok, j'ai maintenant compris le concept, je trouve qu'il est domage que
cette discussion n'ait pas eu lieu plus tot, ca aurait evité, je pense,
pas mal de paroles "mal placées"...
gg
oui et tu as eux besoin de 7 tables et 6 jointures alors que pour la
meme chose MV a une table et aucune jointure
et cela juste pour 2 champs multivalué a 2 niveaux alors imagine une
base ou il y a 1000 champs par enregistrement et qu'il y a 6 niveaux
par exemple
Ok, j'ai maintenant compris le concept, je trouve qu'il est domage que
cette discussion n'ait pas eu lieu plus tot, ca aurait evité, je pense,
pas mal de paroles "mal placées"...
gg
helios a écritALain Montfranc a écrit :helios a écritc'est un champ qui contient des valeurs multiples par exemples les
prénoms , ou les numéros de téléphone ou toute information ayant
plusieurs occurrences
Dans ton exemple date_acte / notaire sont multivalués ?
Comment se fait la jonction date <=> notaire ? On suppose que date[0]
est associé à notaire[0] et ainsi de suite ?
par pédagogie je simplie la notation sans la suite
date_acte [1] correspond a notaire [1]
date_acte [2] correspond a notaire [2]
mais si il y a plusieurs date pour le notaire3
date_acte [3,1] correspond a notaire [3]
date_acte [3,2] correspond a notaire [3]
Ok, effectivement c'est pas mal pour le 1..n
Mais pour le n..n ?
helios a écrit
ALain Montfranc a écrit :
helios a écrit
c'est un champ qui contient des valeurs multiples par exemples les
prénoms , ou les numéros de téléphone ou toute information ayant
plusieurs occurrences
Dans ton exemple date_acte / notaire sont multivalués ?
Comment se fait la jonction date <=> notaire ? On suppose que date[0]
est associé à notaire[0] et ainsi de suite ?
par pédagogie je simplie la notation sans la suite
date_acte [1] correspond a notaire [1]
date_acte [2] correspond a notaire [2]
mais si il y a plusieurs date pour le notaire3
date_acte [3,1] correspond a notaire [3]
date_acte [3,2] correspond a notaire [3]
Ok, effectivement c'est pas mal pour le 1..n
Mais pour le n..n ?
helios a écritALain Montfranc a écrit :helios a écritc'est un champ qui contient des valeurs multiples par exemples les
prénoms , ou les numéros de téléphone ou toute information ayant
plusieurs occurrences
Dans ton exemple date_acte / notaire sont multivalués ?
Comment se fait la jonction date <=> notaire ? On suppose que date[0]
est associé à notaire[0] et ainsi de suite ?
par pédagogie je simplie la notation sans la suite
date_acte [1] correspond a notaire [1]
date_acte [2] correspond a notaire [2]
mais si il y a plusieurs date pour le notaire3
date_acte [3,1] correspond a notaire [3]
date_acte [3,2] correspond a notaire [3]
Ok, effectivement c'est pas mal pour le 1..n
Mais pour le n..n ?
