Avantages/inconvénients d'un système multivalué

Le
sanscorps
En lisant l'historique de ce groupe de discussions j'ai essayé sans y
arriver de trouver des éléments concrets permettant de dresser un
tableau avantage/inconvénient d'un SGBD multivalué par rapport à un
SGBD monovalué.

Je ne comprends pas ce qu'un SGBD multivalué sait faire de plus qu'un
SGBD ? Si j'ai bien compris le SGBD MV permet d'éviter de faire des
relations en ayant des champs multivalués, est-ce la seule
différence ? Existe-t-il des études pour comparer la performance en
temps d'accès et de réponse d'un SGBD MV et SGBD monovalué ? Est-ce
qu'un des deux systèmes est plus performant lorsque les tables sont
importantes (plusieurs millions de lignes) ?

Merci de ne pas troller et d'apporter des éléments concrets sans
comparer des produits mais juste les conceptsmerci d'avance.

Sanscorps
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
helios services
Le #21889101
a écrit :
En lisant l'historique de ce groupe de discussions j'ai essayé sans y
arriver de trouver des éléments concrets permettant de dresser un
tableau avantage/inconvénient d'un SGBD multivalué par rapport à un
SGBD monovalué.

Je ne comprends pas ce qu'un SGBD multivalué sait faire de plus qu'un
SGBD ? Si j'ai bien compris le SGBD MV permet d'éviter de faire des
relations en ayant des champs multivalués, est-ce la seule
différence ? Existe-t-il des études pour comparer la performance en
temps d'accès et de réponse d'un SGBD MV et SGBD monovalué ? Est-ce
qu'un des deux systèmes est plus performant lorsque les tables sont
importantes (plusieurs millions de lignes) ?

Merci de ne pas troller et d'apporter des éléments concrets sans
comparer des produits mais juste les concepts...merci d'avance.

Sanscorps



eviter des jointures est deja un gain de temps machinne colossal

il y a pas de comparatif MV SQL pour la bonne raison que ceux qui sont
sous MV savent que MV est plus rapide et ceux qui sont sous SQL ne
peuvent pas comprendre le MV
a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo



--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
sanscorps
Le #21889091
a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo



quel intérêt aurait une technologie supposée supérieure, qui ne
publierait aucun comparatif pour montrer sa supériorité au lieu de
rester marginale ?
Votre exemple n'est pas significatif, quel système est le plus évolué
entre un vélo carbone profilé et une pointe de fusée en carton
utilisée dans des clubs de modélisme ?

j'attendais du factuel, afin de dresser un tableau avantage/
inconvénient. J'aurais du mal à expliquer ensuite qu'il n'y aucun
inconvénient d'un système MV par rapport à un système monovalué.

cordialement
helios services
Le #21889081
a écrit :
a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo



quel intérêt aurait une technologie supposée supérieure, qui ne
publierait aucun comparatif pour montrer sa supériorité au lieu de
rester marginale ?
Votre exemple n'est pas significatif, quel système est le plus évolué
entre un vélo carbone profilé et une pointe de fusée en carton
utilisée dans des clubs de modélisme ?

j'attendais du factuel, afin de dresser un tableau avantage/
inconvénient. J'aurais du mal à expliquer ensuite qu'il n'y aucun
inconvénient d'un système MV par rapport à un système monovalué.

cordialement




tu vas sur wikipedia il y a dans la version anglaise l'explication de pick

en matiére de marginal il y a juste 11 millions d'utilisateurs pro
sur les 5 plus gros éditeurs de SGBD 2 sont des éditeurs de SGBDMV

il y a pas de jointure donc le temps machine des jointures est économisé
c'est le type de SGBD le plus répandu dans le monde pro (sauf en france
pour des raisons d'orgueil)

l'inconvenients :
c'est tellement puissant et simple que les universitaires français
refuse d'enseigner ce qui remet en question la complexité en effet
comment dire a des étudiants "je vous emmerde depuis x années avec des
theories fumeuses sur les SGBD et les jointures oublié tout ce n'est pas
nécessaire avec les SGBDMV qui sont plus puissant que SQL"


tu lis une doc de SGBDMV et tu comprendras les avantages par rapport a
SQL ou tu suis un cours par un expert en SGBDMV (en général 1000euro/jour)

--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
sanscorps
Le #21889071
en matiére de marginal il y a juste 11 millions d'utilisateurs pro
sur les 5 plus gros éditeurs de SGBD 2 sont des éditeurs de SGBDMV



11 millions de clients différents ou bien 11 millions d'utilisateurs ?
Où puis-je vérifier cette information ?

il y a pas de jointure donc le temps machine des jointures est économis é
c'est le type de SGBD le plus répandu dans le monde pro (sauf en france
pour des raisons d'orgueil)



le fait qu'il n'y ai pas de jointures ne permet pas de conclure que le
temps machine est meilleur, car si le code derrière est moins
performant sur le MV cela annule le bénéfice. Si je définis un modèl e
simple (base client par exemple), il faudrait que je compare les temps
de réponse pou un SELECT ramenant les mêmes données sous la même
forme. Vu que je n'ai pas le matériel pour mener cette étude et que je
suis persuadé que ce type d'étude a déjà été fait je me permets de
m'adresser ici où j'espère trouver des spécialistes.

c'est tellement puissant et simple que les universitaires français
refuse d'enseigner ce qui remet en question la complexité en effet
comment dire a des étudiants "je vous emmerde depuis x années avec des
theories fumeuses sur les SGBD et les jointures oublié tout ce n'est pas
nécessaire avec les SGBDMV qui sont plus puissant que SQL"



c'est justement pour cela que je cherche à construire une table
avantage/inconvénient
avec des éléments factuels et non pas des comparaisons d'école
maternelle : mon papa est plus fort que le tien ou bien la mienne est
plus grosse

tu lis une doc de SGBDMV et tu comprendras les avantages par rapport a
SQL ou tu suis un cours par un expert en SGBDMV (en général 1000euro/j our)



avez vous un lien pertinent ? car la qualité et la pertinence des
réponses ci dessus ne m'incite pas à dépenser 1000 EURO/jour pour avoi r
des réponses comme "ceux qui sont sous MV savent que MV est plus
rapide", "a quoi bon faire des tests pour comparer ", "c'est tellement
puissant et simple"
helios services
Le #21889061
a écrit :
en matiére de marginal il y a juste 11 millions d'utilisateurs pro
sur les 5 plus gros éditeurs de SGBD 2 sont des éditeurs de SGBDMV



11 millions de clients différents ou bien 11 millions d'utilisateurs ?
Où puis-je vérifier cette information ?




11millions d'utilisateurs

tu demandes les chiffes de vente de chaque editeurs de SGBDMV et additionne



il y a pas de jointure donc le temps machine des jointures est économisé
c'est le type de SGBD le plus répandu dans le monde pro (sauf en france
pour des raisons d'orgueil)



le fait qu'il n'y ai pas de jointures ne permet pas de conclure que le
temps machine est meilleur, car si le code derrière est moins
performant sur le MV cela annule le bénéfice. Si je définis un modèle
simple (base client par exemple), il faudrait que je compare les temps
de réponse pou un SELECT ramenant les mêmes données sous la même
forme. Vu que je n'ai pas le matériel pour mener cette étude et que je
suis persuadé que ce type d'étude a déjà été fait je me permets de
m'adresser ici où j'espère trouver des spécialistes.




pour la qualité du code ce n'est pas du microsoft ou assimilé


c'est tellement puissant et simple que les universitaires français
refuse d'enseigner ce qui remet en question la complexité en effet
comment dire a des étudiants "je vous emmerde depuis x années avec des
theories fumeuses sur les SGBD et les jointures oublié tout ce n'est pas
nécessaire avec les SGBDMV qui sont plus puissant que SQL"



c'est justement pour cela que je cherche à construire une table
avantage/inconvénient
avec des éléments factuels et non pas des comparaisons d'école
maternelle : mon papa est plus fort que le tien ou bien la mienne est
plus grosse

tu lis une doc de SGBDMV et tu comprendras les avantages par rapport a
SQL ou tu suis un cours par un expert en SGBDMV (en général 1000euro/jour)



avez vous un lien pertinent ? car la qualité et la pertinence des
réponses ci dessus ne m'incite pas à dépenser 1000 EURO/jour pour avoir
des réponses comme "ceux qui sont sous MV savent que MV est plus
rapide", "a quoi bon faire des tests pour comparer ", "c'est tellement
puissant et simple"



lis une doc et essais un sgbdmv en free par exemple maverick, winter,
bart ou openqm


--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
JKB
Le #21889051
Le 04-03-2008, à propos de
Re: Avantages/inconvénients d'un système multivalué,
helios services écrivait dans fr.comp.applications.sgbd :
a écrit :
En lisant l'historique de ce groupe de discussions j'ai essayé sans y
arriver de trouver des éléments concrets permettant de dresser un
tableau avantage/inconvénient d'un SGBD multivalué par rapport à un
SGBD monovalué.

Je ne comprends pas ce qu'un SGBD multivalué sait faire de plus qu'un
SGBD ? Si j'ai bien compris le SGBD MV permet d'éviter de faire des
relations en ayant des champs multivalués, est-ce la seule
différence ? Existe-t-il des études pour comparer la performance en
temps d'accès et de réponse d'un SGBD MV et SGBD monovalué ? Est-ce
qu'un des deux systèmes est plus performant lorsque les tables sont
importantes (plusieurs millions de lignes) ?

Merci de ne pas troller et d'apporter des éléments concrets sans
comparer des produits mais juste les concepts...merci d'avance.

Sanscorps



eviter des jointures est deja un gain de temps machinne colossal

il y a pas de comparatif MV SQL pour la bonne raison que ceux qui sont
sous MV savent que MV est plus rapide et ceux qui sont sous SQL ne
peuvent pas comprendre le MV



Prends-nous pour des truffes, on ne te dira rien !

a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo



Des benchs, des benchs, des benchs !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
JKB
Le #21889041
Le 04-03-2008, à propos de
Re: Avantages/inconvénients d'un système multivalué,
helios services écrivait dans fr.comp.applications.sgbd :
a écrit :
a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo



quel intérêt aurait une technologie supposée supérieure, qui ne
publierait aucun comparatif pour montrer sa supériorité au lieu de
rester marginale ?
Votre exemple n'est pas significatif, quel système est le plus évolué
entre un vélo carbone profilé et une pointe de fusée en carton
utilisée dans des clubs de modélisme ?

j'attendais du factuel, afin de dresser un tableau avantage/
inconvénient. J'aurais du mal à expliquer ensuite qu'il n'y aucun
inconvénient d'un système MV par rapport à un système monovalué.

cordialement




tu vas sur wikipedia il y a dans la version anglaise l'explication de pick

en matiére de marginal il y a juste 11 millions d'utilisateurs pro
sur les 5 plus gros éditeurs de SGBD 2 sont des éditeurs de SGBDMV

il y a pas de jointure donc le temps machine des jointures est économisé
c'est le type de SGBD le plus répandu dans le monde pro (sauf en france
l'inconvenients :



Là, tu m'intéresses. Comment fais-tu pour faire du multivalué
_dynamique_ (parce que sinon, cela n'a _aucun_ intérêt) sans faire
peu ou prou des jointures dans le dos de l'utilisateur. Le
multivalué masque ses jointures. C'est un peu comme monsieur
Jourdain qui fait de la prose.

c'est tellement puissant et simple que les universitaires français
refuse d'enseigner ce qui remet en question la complexité en effet
comment dire a des étudiants "je vous emmerde depuis x années avec des
theories fumeuses sur les SGBD et les jointures oublié tout ce n'est pas
nécessaire avec les SGBDMV qui sont plus puissant que SQL"



Je repose ma question.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
helios services
Le #21889001
JKB a écrit :
Le 04-03-2008, à propos de
Re: Avantages/inconvénients d'un système multivalué,
helios services écrivait dans fr.comp.applications.sgbd :
a écrit :
En lisant l'historique de ce groupe de discussions j'ai essayé sans y
arriver de trouver des éléments concrets permettant de dresser un
tableau avantage/inconvénient d'un SGBD multivalué par rapport à un
SGBD monovalué.

Je ne comprends pas ce qu'un SGBD multivalué sait faire de plus qu'un
SGBD ? Si j'ai bien compris le SGBD MV permet d'éviter de faire des
relations en ayant des champs multivalués, est-ce la seule
différence ? Existe-t-il des études pour comparer la performance en
temps d'accès et de réponse d'un SGBD MV et SGBD monovalué ? Est-ce
qu'un des deux systèmes est plus performant lorsque les tables sont
importantes (plusieurs millions de lignes) ?

Merci de ne pas troller et d'apporter des éléments concrets sans
comparer des produits mais juste les concepts...merci d'avance.

Sanscorps


eviter des jointures est deja un gain de temps machinne colossal

il y a pas de comparatif MV SQL pour la bonne raison que ceux qui sont
sous MV savent que MV est plus rapide et ceux qui sont sous SQL ne
peuvent pas comprendre le MV



Prends-nous pour des truffes, on ne te dira rien !

a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo



Des benchs, des benchs, des benchs !

JKB




fait les toi même ou paye pour cela car pourquoi quelqu'un perdrait du
temps pour faire un audit donc le resultat est connu les MV sont trés
superieur à SQL




--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
helios services
Le #21888991
JKB a écrit :
Le 04-03-2008, à propos de
Re: Avantages/inconvénients d'un système multivalué,
helios services écrivait dans fr.comp.applications.sgbd :
a écrit :
a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo


quel intérêt aurait une technologie supposée supérieure, qui ne
publierait aucun comparatif pour montrer sa supériorité au lieu de
rester marginale ?
Votre exemple n'est pas significatif, quel système est le plus évolué
entre un vélo carbone profilé et une pointe de fusée en carton
utilisée dans des clubs de modélisme ?

j'attendais du factuel, afin de dresser un tableau avantage/
inconvénient. J'aurais du mal à expliquer ensuite qu'il n'y aucun
inconvénient d'un système MV par rapport à un système monovalué.

cordialement



tu vas sur wikipedia il y a dans la version anglaise l'explication de pick

en matiére de marginal il y a juste 11 millions d'utilisateurs pro
sur les 5 plus gros éditeurs de SGBD 2 sont des éditeurs de SGBDMV

il y a pas de jointure donc le temps machine des jointures est économisé
c'est le type de SGBD le plus répandu dans le monde pro (sauf en france
l'inconvenients :



Là, tu m'intéresses. Comment fais-tu pour faire du multivalué
_dynamique_ (parce que sinon, cela n'a _aucun_ intérêt) sans faire
peu ou prou des jointures dans le dos de l'utilisateur. Le
multivalué masque ses jointures. C'est un peu comme monsieur
Jourdain qui fait de la prose.




non il ne masque pas il n'en as pas besoin le systeme des dictionnaires
de données et le multivalué supprime la necessité de jointures

c'est tellement puissant et simple que les universitaires français
refuse d'enseigner ce qui remet en question la complexité en effet
comment dire a des étudiants "je vous emmerde depuis x années avec des
theories fumeuses sur les SGBD et les jointures oublié tout ce n'est pas
nécessaire avec les SGBDMV qui sont plus puissant que SQL"



Je repose ma question.

JKB




lis une doc de sgbdmv dans la partie dictionnaire de fichier
--
Dr Thierry HOLZ
HELIOS SERVICES
180 rue de la croix du chene
60250 HEILLES
www.openqm.com02.net
www.pick.com02.net
JKB
Le #21888981
Le 04-03-2008, à propos de
Re: Avantages/inconvénients d'un système multivalué,
helios services écrivait dans fr.comp.applications.sgbd :
JKB a écrit :
Le 04-03-2008, à propos de
Re: Avantages/inconvénients d'un système multivalué,
helios services écrivait dans fr.comp.applications.sgbd :
a écrit :
En lisant l'historique de ce groupe de discussions j'ai essayé sans y
arriver de trouver des éléments concrets permettant de dresser un
tableau avantage/inconvénient d'un SGBD multivalué par rapport à un
SGBD monovalué.

Je ne comprends pas ce qu'un SGBD multivalué sait faire de plus qu'un
SGBD ? Si j'ai bien compris le SGBD MV permet d'éviter de faire des
relations en ayant des champs multivalués, est-ce la seule
différence ? Existe-t-il des études pour comparer la performance en
temps d'accès et de réponse d'un SGBD MV et SGBD monovalué ? Est-ce
qu'un des deux systèmes est plus performant lorsque les tables sont
importantes (plusieurs millions de lignes) ?

Merci de ne pas troller et d'apporter des éléments concrets sans
comparer des produits mais juste les concepts...merci d'avance.

Sanscorps


eviter des jointures est deja un gain de temps machinne colossal

il y a pas de comparatif MV SQL pour la bonne raison que ceux qui sont
sous MV savent que MV est plus rapide et ceux qui sont sous SQL ne
peuvent pas comprendre le MV



Prends-nous pour des truffes, on ne te dira rien !

a quoi bon faire des tests pour comparer la vitesse de pointe d'une
fusée et d'un velo



Des benchs, des benchs, des benchs !

JKB




fait les toi même ou paye pour cela car pourquoi quelqu'un perdrait du
temps pour faire un audit donc le resultat est connu les MV sont trés
superieur à SQL



Non. C'est toi et toi seul qui l'affirme. Personne d'autre.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Publicité
Poster une réponse
Anonyme