la requête lancé pour le test contient la gestion de 90 items et
l'équivalent de 58 jointures en SQL le tout sur 5 fichiers multivalué
(en SQL il aurait fallu 63 tables)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
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 en SQL si une personne à plusieurs prénom il faut créer une jointure vers une table prénom tandis que en SGBDRMV on met tout les prénom dans le champ prénom sans jointure ni table supplémentaire ainsi certain fichier multivalué ont jusque a l'équivalent de 8000 table SQL donc remplace 8000 table SQL et 8000 jointure
Ton exemple se modelise tres bien avec 3 tables, voir l'image http://www.gg-s.net/helios.png , et on est loin de 8000 tables.
J'utilise courrament ce type de structure quand j'ai besoin de caractériser des éléments "de base" (une personne dans notre exemple).
gg
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Jerome PAULIN a écrit :
h
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
en SQL si une personne à plusieurs prénom il faut créer une jointure
vers une table prénom tandis que en SGBDRMV on met tout les prénom
dans le champ prénom sans jointure ni table supplémentaire ainsi
certain fichier multivalué ont jusque a l'équivalent de 8000 table SQL
donc remplace 8000 table SQL et 8000 jointure
Ton exemple se modelise tres bien avec 3 tables, voir l'image
http://www.gg-s.net/helios.png , et on est loin de 8000 tables.
J'utilise courrament ce type de structure quand j'ai besoin de
caractériser des éléments "de base" (une personne dans notre exemple).
gg
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as
besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
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 en SQL si une personne à plusieurs prénom il faut créer une jointure vers une table prénom tandis que en SGBDRMV on met tout les prénom dans le champ prénom sans jointure ni table supplémentaire ainsi certain fichier multivalué ont jusque a l'équivalent de 8000 table SQL donc remplace 8000 table SQL et 8000 jointure
Ton exemple se modelise tres bien avec 3 tables, voir l'image http://www.gg-s.net/helios.png , et on est loin de 8000 tables.
J'utilise courrament ce type de structure quand j'ai besoin de caractériser des éléments "de base" (une personne dans notre exemple).
gg
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
helios
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]
et si il y a plusieurs notaire a la date4
date_acte [4] correspond a notaire [4,1] date_acte [4] correspond a notaire [4,2]
la norme SGBDRMV prévois 128 niveaux de multivalué date_acte [1] 1 niveaux date_acte [3,1] 2 niveaux date_acte [a,b,c,d,e,f,g,h,i,j] 10 niveaux
les SGBRMV sont des SGBDR à multi-niveau de données les SGBDRMD et XML aussi
l'année 2007 étant celle de la convergence des trois type de SGBDR à multiniveaux
Dr Thierry HOLZ helios services 180 rue de la croix du chene 60250 HEILLES www.openqm.com02.net www.pick.com02.net
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]
et si il y a plusieurs notaire a la date4
date_acte [4] correspond a notaire [4,1]
date_acte [4] correspond a notaire [4,2]
la norme SGBDRMV prévois 128 niveaux de multivalué
date_acte [1] 1 niveaux
date_acte [3,1] 2 niveaux
date_acte [a,b,c,d,e,f,g,h,i,j] 10 niveaux
les SGBRMV sont des SGBDR à multi-niveau de données
les SGBDRMD et XML aussi
l'année 2007 étant celle de la convergence des trois type de SGBDR à
multiniveaux
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
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]
et si il y a plusieurs notaire a la date4
date_acte [4] correspond a notaire [4,1] date_acte [4] correspond a notaire [4,2]
la norme SGBDRMV prévois 128 niveaux de multivalué date_acte [1] 1 niveaux date_acte [3,1] 2 niveaux date_acte [a,b,c,d,e,f,g,h,i,j] 10 niveaux
les SGBRMV sont des SGBDR à multi-niveau de données les SGBDRMD et XML aussi
l'année 2007 étant celle de la convergence des trois type de SGBDR à multiniveaux
Dr Thierry HOLZ helios services 180 rue de la croix du chene 60250 HEILLES www.openqm.com02.net www.pick.com02.net
helios
ALain Montfranc a écrit :
helios a écrit
non
c'est une messagerie instantanée soit dispositif informatique qui permet
Tu vois, c'est important de se synchroniser sur les définitions ;-D
non ce qui est important c'est de savoir que ici c'est les SGBD et non la zoologie et accessoirement l'internet
ALain Montfranc a écrit :
helios a écrit
non
c'est une messagerie instantanée soit dispositif informatique qui permet
Tu vois, c'est important de se synchroniser sur les définitions ;-D
non ce qui est important c'est de savoir que ici c'est les SGBD et non
la zoologie et accessoirement l'internet
c'est une messagerie instantanée soit dispositif informatique qui permet
Tu vois, c'est important de se synchroniser sur les définitions ;-D
non ce qui est important c'est de savoir que ici c'est les SGBD et non la zoologie et accessoirement l'internet
Jerome PAULIN
helios a écrit :
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des champs dans la table t_type_caracteristique_personne pour pouvoir ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans t_type_caracteristique_personne, dans t_caracteristique personne, il y aura autant d'enregistrements que dans les champs MV renseignés (par exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la caractéristique "prénom" pour la même personne ...
gg
helios a écrit :
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as
besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des
champs dans la table t_type_caracteristique_personne pour pouvoir
ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans
t_type_caracteristique_personne, dans t_caracteristique personne, il y
aura autant d'enregistrements que dans les champs MV renseignés (par
exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la
caractéristique "prénom" pour la même personne ...
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des champs dans la table t_type_caracteristique_personne pour pouvoir ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans t_type_caracteristique_personne, dans t_caracteristique personne, il y aura autant d'enregistrements que dans les champs MV renseignés (par exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la caractéristique "prénom" pour la même personne ...
gg
helios
Jerome PAULIN a écrit :
helios a écrit :
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des champs dans la table t_type_caracteristique_personne pour pouvoir ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans t_type_caracteristique_personne, dans t_caracteristique personne, il y aura autant d'enregistrements que dans les champs MV renseignés (par exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la caractéristique "prénom" pour la même personne ...
gg
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de ligne et colonne
les "case" contiennent une valeur ou une jointures
si tu préfères pour simplifié
les article sont les lignes
les champs les colonne
les valeurs multivalué sont une jointure avec une table
les sous-valeurs sont une jointure vers une table qui contient des jointures vers d'autre table
les sous-sous-valeurs sont une jointure vers une table qui contient des jointures vers des tables qui contiennent des jointure vers des tables
les sous-sous-sous-valeurs ......
il y a 128 niveaux possible
Jerome PAULIN a écrit :
helios a écrit :
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu
as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des
champs dans la table t_type_caracteristique_personne pour pouvoir
ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans
t_type_caracteristique_personne, dans t_caracteristique personne, il y
aura autant d'enregistrements que dans les champs MV renseignés (par
exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la
caractéristique "prénom" pour la même personne ...
gg
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de
ligne et colonne
les "case" contiennent une valeur ou une jointures
si tu préfères pour simplifié
les article sont les lignes
les champs les colonne
les valeurs multivalué sont une jointure avec une table
les sous-valeurs sont une jointure vers une table qui contient des
jointures vers d'autre table
les sous-sous-valeurs sont une jointure vers une table qui contient des
jointures vers des tables qui contiennent des jointure vers des tables
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des champs dans la table t_type_caracteristique_personne pour pouvoir ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans t_type_caracteristique_personne, dans t_caracteristique personne, il y aura autant d'enregistrements que dans les champs MV renseignés (par exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la caractéristique "prénom" pour la même personne ...
gg
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de ligne et colonne
les "case" contiennent une valeur ou une jointures
si tu préfères pour simplifié
les article sont les lignes
les champs les colonne
les valeurs multivalué sont une jointure avec une table
les sous-valeurs sont une jointure vers une table qui contient des jointures vers d'autre table
les sous-sous-valeurs sont une jointure vers une table qui contient des jointures vers des tables qui contiennent des jointure vers des tables
les sous-sous-sous-valeurs ......
il y a 128 niveaux possible
Jerome PAULIN
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de ligne et colonne
les "case" contiennent une valeur ou une jointures
Comme si les cases contenaient des couches empilées, chaque couche etant un ensemble de valeurs, avec 128 couches possibles ?
gg
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de
ligne et colonne
les "case" contiennent une valeur ou une jointures
Comme si les cases contenaient des couches empilées, chaque couche etant
un ensemble de valeurs, avec 128 couches possibles ?
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de ligne et colonne
les "case" contiennent une valeur ou une jointures
Comme si les cases contenaient des couches empilées, chaque couche etant un ensemble de valeurs, avec 128 couches possibles ?
gg
helios
Jerome PAULIN a écrit :
helios a écrit :
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des champs dans la table t_type_caracteristique_personne pour pouvoir ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans t_type_caracteristique_personne, dans t_caracteristique personne, il y aura autant d'enregistrements que dans les champs MV renseignés (par exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la caractéristique "prénom" pour la même personne ...
gg
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
Jerome PAULIN a écrit :
helios a écrit :
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu
as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des
champs dans la table t_type_caracteristique_personne pour pouvoir
ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans
t_type_caracteristique_personne, dans t_caracteristique personne, il y
aura autant d'enregistrements que dans les champs MV renseignés (par
exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la
caractéristique "prénom" pour la même personne ...
gg
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
mais mon exemple est sur 3 champs pas sur 8000 champs donc en SQL tu as besoin de 3 table pour 3 champs et 8000 tables pour 8000 champs
Justement, il n'y a pas besoin de 8000 tables, il suffit d'ajouter des champs dans la table t_type_caracteristique_personne pour pouvoir ajouter des valeurs differentes.
S'il y a 8000 champs au départ, il y aura 8000 enregistrements dans t_type_caracteristique_personne, dans t_caracteristique personne, il y aura autant d'enregistrements que dans les champs MV renseignés (par exemple, rien ne s'oppose au fait de mettre plusieurs valeurs ayant la caractéristique "prénom" pour la même personne ...
gg
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
helios
Jerome PAULIN a écrit :
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de ligne et colonne
les "case" contiennent une valeur ou une jointures
Comme si les cases contenaient des couches empilées, chaque couche etant un ensemble de valeurs, avec 128 couches possibles ?
gg
oui
cela evites toute les jointures en cascades et les tables jointes ce qui evites de lours traitement de jointure et rend donc les SGBDR beaucoup plus performant et facilite l'evolution d'une base
exemple dans la modelisation j'ai pas pense que la valeur du champ 150 des enregistrements devait etre multiple
en SQL il faut que je restruture completement ma base pour remplacer les valeur par une table jointe avec une jointure tandis que en SGBDRMV j'ajoute simplement les autres valeurs de la valeur du champ 150 dans les enregistrements concerné pour que celle ci deviennne multivalué
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é)
Dr Thierry HOLZ helios services 180 rue de la croix du chene 60250 HEILLES www.openqm.com02.net www.pick.com02.net
Jerome PAULIN a écrit :
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de
ligne et colonne
les "case" contiennent une valeur ou une jointures
Comme si les cases contenaient des couches empilées, chaque couche etant
un ensemble de valeurs, avec 128 couches possibles ?
gg
oui
cela evites toute les jointures en cascades et les tables jointes ce qui
evites de lours traitement de jointure et rend donc les SGBDR beaucoup
plus performant et facilite l'evolution d'une base
exemple
dans la modelisation j'ai pas pense que la valeur du champ 150 des
enregistrements devait etre multiple
en SQL il faut que je restruture completement ma base pour remplacer les
valeur par une table jointe avec une jointure tandis que en SGBDRMV
j'ajoute simplement les autres valeurs de la valeur du champ 150 dans
les enregistrements concerné pour que celle ci deviennne multivalué
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é)
Dr Thierry HOLZ
helios services
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
un fichier de 8000 champs n'est pas un fichier de 8000 valeurs
un fichiers MV est constitué
articles ayant des champs qui ont des valeurs des sous valeur ......
les "case" contiennent une valeur simple ou une valeur multivalué
un fichier SQL (table) est constitué de ligne et colonne
les "case" contiennent une valeur ou une jointures
Comme si les cases contenaient des couches empilées, chaque couche etant un ensemble de valeurs, avec 128 couches possibles ?
gg
oui
cela evites toute les jointures en cascades et les tables jointes ce qui evites de lours traitement de jointure et rend donc les SGBDR beaucoup plus performant et facilite l'evolution d'une base
exemple dans la modelisation j'ai pas pense que la valeur du champ 150 des enregistrements devait etre multiple
en SQL il faut que je restruture completement ma base pour remplacer les valeur par une table jointe avec une jointure tandis que en SGBDRMV j'ajoute simplement les autres valeurs de la valeur du champ 150 dans les enregistrements concerné pour que celle ci deviennne multivalué
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é)
Dr Thierry HOLZ helios services 180 rue de la croix du chene 60250 HEILLES www.openqm.com02.net www.pick.com02.net
Jerome PAULIN
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)?
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
Jerome PAULIN
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)?
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)?
