Racimo a écrit :
> Ci dessous les réponses aux points soulevés...
>
> <<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
> dire de telles anneries.>>
> Si vous pensez que je raconte des anneries sans donner le moindre argument
> pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
> que je peux dire c'est que j'ai eu l'opportunité de tester ces
> fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
> millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
> sont pragmatiques (j'ai vite abandonné cette solution).
et pour cause, les SGBDR ne sont pas fait pour stocker des images
principalement mais des données interrogeable par des requêtes SQL;
Allez vous faire une requête SQL du genre :
je cherche une image dans laquelle il y a un chien jaune ???
Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
votre propre bétise...
C'est comme les gens qui préfèrent utiliser une ferrari et constate que
pour faire un déménagement cela leur coûte plus cher en aller et retour
que d'avoir pris un camion... Mais n'en tire pas pour autant la bonne
conclusion et vont voir ferrari en les injuriant...
> Pouvez-vous en dire
> autant pour dire que je raconte des anneries et que vous avez raison? Quelle
> la plus grosse base binaire que vous avez géré au jour le jour?
un peu plus de 850 Go
>
>
> <<En particulier le type XML de SQL Server 2005 est assez performant
> lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
> Oracle par exemple.
> SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
> validé et contre validabe, indexable et requêtable (à l'aide de XPath et
> XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
>
> Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
> l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
> de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
> strictement RIEN au data management)...
XML a été créé essentiellement pour l'EDI comme en témoigne des sites
comme http://www.rosettanet.org/
Ce n'est pas non plus une solution de manipulation de données en bases
de données.
> Les débats stériles du type SQL est
> mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
> qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
> "APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
> Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
> words)
>
> <<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
> être utilisé parcimonieusement et base de données XML comme Tamino d'AG
> Software.>>
>
> XML est une abbération un point c'est tout.
ce genre d'argument prouve bien votre inculture !
Désolé mais il me parait difficile de continuer un débat aussi stérile
sur des arguments aussi stupides !!!
> Et ce sous n'importe quel type
> d'implémentation . Il constitue une regression au niveau de modèle
> hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
> sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
> une telle structure. C'est aussi la raison pour laquelle le modèle
> relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
> en dira plus...
>
> http://www.joelonsoftware.com/articles/fog0000000319.html
>
> <<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
> de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
> l'air d'oublier !>>
> Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
> souvent pas en mesure de voir ce genre de nuance....
>
> <<Donnez des noms, des faits, des mesures et des papiers sur le sujet
> !>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
> d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
> des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
> partie de leur argumentaire commercial? Cette information, je la tiens d'un
> collègue travaillant actuellement à Edmonton et qui a participé directement
> au developpement du produit. Je ne révèlerai pas son nom pour des raisons
> évidentes: cette personne travaille encore chez MS.
>
Pas de preuve = faux !
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Racimo a écrit :
> Ci dessous les réponses aux points soulevés...
>
> <<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
> dire de telles anneries.>>
> Si vous pensez que je raconte des anneries sans donner le moindre argument
> pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
> que je peux dire c'est que j'ai eu l'opportunité de tester ces
> fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
> millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
> sont pragmatiques (j'ai vite abandonné cette solution).
et pour cause, les SGBDR ne sont pas fait pour stocker des images
principalement mais des données interrogeable par des requêtes SQL;
Allez vous faire une requête SQL du genre :
je cherche une image dans laquelle il y a un chien jaune ???
Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
votre propre bétise...
C'est comme les gens qui préfèrent utiliser une ferrari et constate que
pour faire un déménagement cela leur coûte plus cher en aller et retour
que d'avoir pris un camion... Mais n'en tire pas pour autant la bonne
conclusion et vont voir ferrari en les injuriant...
> Pouvez-vous en dire
> autant pour dire que je raconte des anneries et que vous avez raison? Quelle
> la plus grosse base binaire que vous avez géré au jour le jour?
un peu plus de 850 Go
>
>
> <<En particulier le type XML de SQL Server 2005 est assez performant
> lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
> Oracle par exemple.
> SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
> validé et contre validabe, indexable et requêtable (à l'aide de XPath et
> XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
>
> Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
> l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
> de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
> strictement RIEN au data management)...
XML a été créé essentiellement pour l'EDI comme en témoigne des sites
comme http://www.rosettanet.org/
Ce n'est pas non plus une solution de manipulation de données en bases
de données.
> Les débats stériles du type SQL est
> mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
> qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
> "APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
> Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
> words)
>
> <<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
> être utilisé parcimonieusement et base de données XML comme Tamino d'AG
> Software.>>
>
> XML est une abbération un point c'est tout.
ce genre d'argument prouve bien votre inculture !
Désolé mais il me parait difficile de continuer un débat aussi stérile
sur des arguments aussi stupides !!!
> Et ce sous n'importe quel type
> d'implémentation . Il constitue une regression au niveau de modèle
> hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
> sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
> une telle structure. C'est aussi la raison pour laquelle le modèle
> relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
> en dira plus...
>
> http://www.joelonsoftware.com/articles/fog0000000319.html
>
> <<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
> de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
> l'air d'oublier !>>
> Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
> souvent pas en mesure de voir ce genre de nuance....
>
> <<Donnez des noms, des faits, des mesures et des papiers sur le sujet
> !>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
> d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
> des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
> partie de leur argumentaire commercial? Cette information, je la tiens d'un
> collègue travaillant actuellement à Edmonton et qui a participé directement
> au developpement du produit. Je ne révèlerai pas son nom pour des raisons
> évidentes: cette personne travaille encore chez MS.
>
Pas de preuve = faux !
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Racimo a écrit :
> Ci dessous les réponses aux points soulevés...
>
> <<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
> dire de telles anneries.>>
> Si vous pensez que je raconte des anneries sans donner le moindre argument
> pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
> que je peux dire c'est que j'ai eu l'opportunité de tester ces
> fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
> millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
> sont pragmatiques (j'ai vite abandonné cette solution).
et pour cause, les SGBDR ne sont pas fait pour stocker des images
principalement mais des données interrogeable par des requêtes SQL;
Allez vous faire une requête SQL du genre :
je cherche une image dans laquelle il y a un chien jaune ???
Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
votre propre bétise...
C'est comme les gens qui préfèrent utiliser une ferrari et constate que
pour faire un déménagement cela leur coûte plus cher en aller et retour
que d'avoir pris un camion... Mais n'en tire pas pour autant la bonne
conclusion et vont voir ferrari en les injuriant...
> Pouvez-vous en dire
> autant pour dire que je raconte des anneries et que vous avez raison? Quelle
> la plus grosse base binaire que vous avez géré au jour le jour?
un peu plus de 850 Go
>
>
> <<En particulier le type XML de SQL Server 2005 est assez performant
> lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
> Oracle par exemple.
> SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
> validé et contre validabe, indexable et requêtable (à l'aide de XPath et
> XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
>
> Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
> l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
> de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
> strictement RIEN au data management)...
XML a été créé essentiellement pour l'EDI comme en témoigne des sites
comme http://www.rosettanet.org/
Ce n'est pas non plus une solution de manipulation de données en bases
de données.
> Les débats stériles du type SQL est
> mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
> qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
> "APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
> Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
> words)
>
> <<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
> être utilisé parcimonieusement et base de données XML comme Tamino d'AG
> Software.>>
>
> XML est une abbération un point c'est tout.
ce genre d'argument prouve bien votre inculture !
Désolé mais il me parait difficile de continuer un débat aussi stérile
sur des arguments aussi stupides !!!
> Et ce sous n'importe quel type
> d'implémentation . Il constitue une regression au niveau de modèle
> hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
> sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
> une telle structure. C'est aussi la raison pour laquelle le modèle
> relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
> en dira plus...
>
> http://www.joelonsoftware.com/articles/fog0000000319.html
>
> <<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
> de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
> l'air d'oublier !>>
> Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
> souvent pas en mesure de voir ce genre de nuance....
>
> <<Donnez des noms, des faits, des mesures et des papiers sur le sujet
> !>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
> d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
> des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
> partie de leur argumentaire commercial? Cette information, je la tiens d'un
> collègue travaillant actuellement à Edmonton et qui a participé directement
> au developpement du produit. Je ne révèlerai pas son nom pour des raisons
> évidentes: cette personne travaille encore chez MS.
>
Pas de preuve = faux !
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
<<Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
votre propre bétise...>>
J'ai utilisé un SGBD vantant les mérites de pouvoir stocker des binaires en
base. J'ai du apprendre à mes dépens la faiblesse de cette fonctionnalité.
<<ce genre d'argument prouve bien votre inculture !>>
Ce débat est effectivement un perte de mon temps car nous ne parlons pas de
la même chose...Voila maintenant que vous m'attaquez personnellement parce
vous n'avez de réponse probante au points et questions que j'ai
soulevé...Votre attitude est trop agressive pour un débat serein.
<<un peu plus de 850 Go>>
Je ne vous crois pas. Donnez moi les conditions d'execution, décrivez
l'activité...
<<Désolé mais il me parait difficile de continuer un débat aussi stérile
sur des arguments aussi stupides !!!>>
<<Pas de preuve = faux !>>
J'ai fourni au cours de cette thread des arguments tirés de publication,
d'experience pratique...Le seul argument que vous avez pu fournir est une
analogie avec une voiture --> Si vous comparez les sgbd avec les voitures
pour pouvoir expliquer quelque chose, il me semble clair que vous n'avez ni
les arguments, ni encore l'honneteté intellectuelle de reconnaitre...Celà
traduit d'une ignorance réelle du data management et notamment des règles du
modèle relationel pour que nous ayon une discussion intelligente...
Je propose que nous nous mettions d'accord pour ne pas être d'accord ;)
"SQLpro [MVP]" a écrit :
> Racimo a écrit :
> > Ci dessous les réponses aux points soulevés...
> >
> > <<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
> > dire de telles anneries.>>
> > Si vous pensez que je raconte des anneries sans donner le moindre argument
> > pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
> > que je peux dire c'est que j'ai eu l'opportunité de tester ces
> > fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
> > millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
> > sont pragmatiques (j'ai vite abandonné cette solution).
>
> et pour cause, les SGBDR ne sont pas fait pour stocker des images
> principalement mais des données interrogeable par des requêtes SQL;
> Allez vous faire une requête SQL du genre :
> je cherche une image dans laquelle il y a un chien jaune ???
>
> Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
> votre propre bétise...
>
> C'est comme les gens qui préfèrent utiliser une ferrari et constate que
> pour faire un déménagement cela leur coûte plus cher en aller et retour
> que d'avoir pris un camion... Mais n'en tire pas pour autant la bonne
> conclusion et vont voir ferrari en les injuriant...
>
> > Pouvez-vous en dire
> > autant pour dire que je raconte des anneries et que vous avez raison? Quelle
> > la plus grosse base binaire que vous avez géré au jour le jour?
>
> un peu plus de 850 Go
>
> >
> >
> > <<En particulier le type XML de SQL Server 2005 est assez performant
> > lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
> > Oracle par exemple.
> > SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
> > validé et contre validabe, indexable et requêtable (à l'aide de XPath et
> > XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
> >
> > Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
> > l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
> > de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
> > strictement RIEN au data management)...
>
> XML a été créé essentiellement pour l'EDI comme en témoigne des sites
> comme http://www.rosettanet.org/
>
> Ce n'est pas non plus une solution de manipulation de données en bases
> de données.
>
>
> > Les débats stériles du type SQL est
> > mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
> > qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
> > "APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
> > Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
> > words)
> >
> > <<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
> > être utilisé parcimonieusement et base de données XML comme Tamino d'AG
> > Software.>>
> >
> > XML est une abbération un point c'est tout.
>
>
> ce genre d'argument prouve bien votre inculture !
>
> Désolé mais il me parait difficile de continuer un débat aussi stérile
> sur des arguments aussi stupides !!!
>
> > Et ce sous n'importe quel type
> > d'implémentation . Il constitue une regression au niveau de modèle
> > hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
> > sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
> > une telle structure. C'est aussi la raison pour laquelle le modèle
> > relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
> > en dira plus...
> >
> > http://www.joelonsoftware.com/articles/fog0000000319.html
> >
> > <<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
> > de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
> > l'air d'oublier !>>
> > Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
> > souvent pas en mesure de voir ce genre de nuance....
> >
> > <<Donnez des noms, des faits, des mesures et des papiers sur le sujet
> > !>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
> > d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
> > des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
> > partie de leur argumentaire commercial? Cette information, je la tiens d'un
> > collègue travaillant actuellement à Edmonton et qui a participé directement
> > au developpement du produit. Je ne révèlerai pas son nom pour des raisons
> > évidentes: cette personne travaille encore chez MS.
> >
>
> Pas de preuve = faux !
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
<<Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
votre propre bétise...>>
J'ai utilisé un SGBD vantant les mérites de pouvoir stocker des binaires en
base. J'ai du apprendre à mes dépens la faiblesse de cette fonctionnalité.
<<ce genre d'argument prouve bien votre inculture !>>
Ce débat est effectivement un perte de mon temps car nous ne parlons pas de
la même chose...Voila maintenant que vous m'attaquez personnellement parce
vous n'avez de réponse probante au points et questions que j'ai
soulevé...Votre attitude est trop agressive pour un débat serein.
<<un peu plus de 850 Go>>
Je ne vous crois pas. Donnez moi les conditions d'execution, décrivez
l'activité...
<<Désolé mais il me parait difficile de continuer un débat aussi stérile
sur des arguments aussi stupides !!!>>
<<Pas de preuve = faux !>>
J'ai fourni au cours de cette thread des arguments tirés de publication,
d'experience pratique...Le seul argument que vous avez pu fournir est une
analogie avec une voiture --> Si vous comparez les sgbd avec les voitures
pour pouvoir expliquer quelque chose, il me semble clair que vous n'avez ni
les arguments, ni encore l'honneteté intellectuelle de reconnaitre...Celà
traduit d'une ignorance réelle du data management et notamment des règles du
modèle relationel pour que nous ayon une discussion intelligente...
Je propose que nous nous mettions d'accord pour ne pas être d'accord ;)
"SQLpro [MVP]" a écrit :
> Racimo a écrit :
> > Ci dessous les réponses aux points soulevés...
> >
> > <<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
> > dire de telles anneries.>>
> > Si vous pensez que je raconte des anneries sans donner le moindre argument
> > pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
> > que je peux dire c'est que j'ai eu l'opportunité de tester ces
> > fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
> > millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
> > sont pragmatiques (j'ai vite abandonné cette solution).
>
> et pour cause, les SGBDR ne sont pas fait pour stocker des images
> principalement mais des données interrogeable par des requêtes SQL;
> Allez vous faire une requête SQL du genre :
> je cherche une image dans laquelle il y a un chien jaune ???
>
> Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
> votre propre bétise...
>
> C'est comme les gens qui préfèrent utiliser une ferrari et constate que
> pour faire un déménagement cela leur coûte plus cher en aller et retour
> que d'avoir pris un camion... Mais n'en tire pas pour autant la bonne
> conclusion et vont voir ferrari en les injuriant...
>
> > Pouvez-vous en dire
> > autant pour dire que je raconte des anneries et que vous avez raison? Quelle
> > la plus grosse base binaire que vous avez géré au jour le jour?
>
> un peu plus de 850 Go
>
> >
> >
> > <<En particulier le type XML de SQL Server 2005 est assez performant
> > lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
> > Oracle par exemple.
> > SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
> > validé et contre validabe, indexable et requêtable (à l'aide de XPath et
> > XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
> >
> > Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
> > l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
> > de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
> > strictement RIEN au data management)...
>
> XML a été créé essentiellement pour l'EDI comme en témoigne des sites
> comme http://www.rosettanet.org/
>
> Ce n'est pas non plus une solution de manipulation de données en bases
> de données.
>
>
> > Les débats stériles du type SQL est
> > mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
> > qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
> > "APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
> > Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
> > words)
> >
> > <<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
> > être utilisé parcimonieusement et base de données XML comme Tamino d'AG
> > Software.>>
> >
> > XML est une abbération un point c'est tout.
>
>
> ce genre d'argument prouve bien votre inculture !
>
> Désolé mais il me parait difficile de continuer un débat aussi stérile
> sur des arguments aussi stupides !!!
>
> > Et ce sous n'importe quel type
> > d'implémentation . Il constitue une regression au niveau de modèle
> > hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
> > sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
> > une telle structure. C'est aussi la raison pour laquelle le modèle
> > relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
> > en dira plus...
> >
> > http://www.joelonsoftware.com/articles/fog0000000319.html
> >
> > <<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
> > de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
> > l'air d'oublier !>>
> > Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
> > souvent pas en mesure de voir ce genre de nuance....
> >
> > <<Donnez des noms, des faits, des mesures et des papiers sur le sujet
> > !>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
> > d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
> > des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
> > partie de leur argumentaire commercial? Cette information, je la tiens d'un
> > collègue travaillant actuellement à Edmonton et qui a participé directement
> > au developpement du produit. Je ne révèlerai pas son nom pour des raisons
> > évidentes: cette personne travaille encore chez MS.
> >
>
> Pas de preuve = faux !
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
<<Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
votre propre bétise...>>
J'ai utilisé un SGBD vantant les mérites de pouvoir stocker des binaires en
base. J'ai du apprendre à mes dépens la faiblesse de cette fonctionnalité.
<<ce genre d'argument prouve bien votre inculture !>>
Ce débat est effectivement un perte de mon temps car nous ne parlons pas de
la même chose...Voila maintenant que vous m'attaquez personnellement parce
vous n'avez de réponse probante au points et questions que j'ai
soulevé...Votre attitude est trop agressive pour un débat serein.
<<un peu plus de 850 Go>>
Je ne vous crois pas. Donnez moi les conditions d'execution, décrivez
l'activité...
<<Désolé mais il me parait difficile de continuer un débat aussi stérile
sur des arguments aussi stupides !!!>>
<<Pas de preuve = faux !>>
J'ai fourni au cours de cette thread des arguments tirés de publication,
d'experience pratique...Le seul argument que vous avez pu fournir est une
analogie avec une voiture --> Si vous comparez les sgbd avec les voitures
pour pouvoir expliquer quelque chose, il me semble clair que vous n'avez ni
les arguments, ni encore l'honneteté intellectuelle de reconnaitre...Celà
traduit d'une ignorance réelle du data management et notamment des règles du
modèle relationel pour que nous ayon une discussion intelligente...
Je propose que nous nous mettions d'accord pour ne pas être d'accord ;)
"SQLpro [MVP]" a écrit :
> Racimo a écrit :
> > Ci dessous les réponses aux points soulevés...
> >
> > <<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
> > dire de telles anneries.>>
> > Si vous pensez que je raconte des anneries sans donner le moindre argument
> > pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
> > que je peux dire c'est que j'ai eu l'opportunité de tester ces
> > fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
> > millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
> > sont pragmatiques (j'ai vite abandonné cette solution).
>
> et pour cause, les SGBDR ne sont pas fait pour stocker des images
> principalement mais des données interrogeable par des requêtes SQL;
> Allez vous faire une requête SQL du genre :
> je cherche une image dans laquelle il y a un chien jaune ???
>
> Vous avez utilisé un SGBDR massivement à contre emploi et avez constaté
> votre propre bétise...
>
> C'est comme les gens qui préfèrent utiliser une ferrari et constate que
> pour faire un déménagement cela leur coûte plus cher en aller et retour
> que d'avoir pris un camion... Mais n'en tire pas pour autant la bonne
> conclusion et vont voir ferrari en les injuriant...
>
> > Pouvez-vous en dire
> > autant pour dire que je raconte des anneries et que vous avez raison? Quelle
> > la plus grosse base binaire que vous avez géré au jour le jour?
>
> un peu plus de 850 Go
>
> >
> >
> > <<En particulier le type XML de SQL Server 2005 est assez performant
> > lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
> > Oracle par exemple.
> > SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
> > validé et contre validabe, indexable et requêtable (à l'aide de XPath et
> > XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
> >
> > Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
> > l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
> > de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
> > strictement RIEN au data management)...
>
> XML a été créé essentiellement pour l'EDI comme en témoigne des sites
> comme http://www.rosettanet.org/
>
> Ce n'est pas non plus une solution de manipulation de données en bases
> de données.
>
>
> > Les débats stériles du type SQL est
> > mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
> > qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
> > "APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
> > Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
> > words)
> >
> > <<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
> > être utilisé parcimonieusement et base de données XML comme Tamino d'AG
> > Software.>>
> >
> > XML est une abbération un point c'est tout.
>
>
> ce genre d'argument prouve bien votre inculture !
>
> Désolé mais il me parait difficile de continuer un débat aussi stérile
> sur des arguments aussi stupides !!!
>
> > Et ce sous n'importe quel type
> > d'implémentation . Il constitue une regression au niveau de modèle
> > hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
> > sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
> > une telle structure. C'est aussi la raison pour laquelle le modèle
> > relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
> > en dira plus...
> >
> > http://www.joelonsoftware.com/articles/fog0000000319.html
> >
> > <<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
> > de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
> > l'air d'oublier !>>
> > Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
> > souvent pas en mesure de voir ce genre de nuance....
> >
> > <<Donnez des noms, des faits, des mesures et des papiers sur le sujet
> > !>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
> > d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
> > des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
> > partie de leur argumentaire commercial? Cette information, je la tiens d'un
> > collègue travaillant actuellement à Edmonton et qui a participé directement
> > au developpement du produit. Je ne révèlerai pas son nom pour des raisons
> > évidentes: cette personne travaille encore chez MS.
> >
>
> Pas de preuve = faux !
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
Ci dessous les réponses aux points soulevés...
<<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.>>
Si vous pensez que je raconte des anneries sans donner le moindre argument
pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...
Ci dessous les réponses aux points soulevés...
<<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.>>
Si vous pensez que je raconte des anneries sans donner le moindre argument
pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...
Ci dessous les réponses aux points soulevés...
<<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.>>
Si vous pensez que je raconte des anneries sans donner le moindre argument
pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...
