[Confirme] Réf. : [Confirme] Réf. : Re: [Confirme] Re: Corporate Server [Hors Sujet SGBD]
Pour enrichir votre débat : On peut utiliser sous Linux un SGBDR hyper-bétonné et tout à fait complet : SYBASE. Il est libre en téléchargement sur www.sybase.com. Je pratique professionnellement ce SGBD sur AIX /RS6000 et personnellement sur un portable avec Mandrake7.1 sans PB d'aucune sorte, ni écart décelable de comportement entre les deux versions (aux perfs près, mais on ne parle pas des mêmes machines) Par contre, je ne me suis pas penché sur l'utilisation professionnelle sous Linux (licences ?) [EMAIL PROTECTED]@linux-mandrake.com le 01/12/2000 12:06:22 Veuillez répondre à [EMAIL PROTECTED] Envoyé par : [EMAIL PROTECTED] Pour :[EMAIL PROTECTED] cc : Objet : [Confirme] Réf. : Re: [Confirme] Re: Corporate Server [Hors Sujet SGBD] Alain Tésio <[EMAIL PROTECTED]>Pour : "[EMAIL PROTECTED]" Envoyé par : <[EMAIL PROTECTED]> confirme-owner@linux-macc : ndrake.com Objet : Re: [Confirme] Re: Corporate Server 16/11/00 00:56 Veuillez répondre à confirme Réponse tardive, pas la pendant 2 demaines. > [EMAIL PROTECTED] a écrit : > > > Le plus gros problème dans le lot, c\'est MySQL: > > il faut vraiment avoir des besoins très limités pour l\'utiliser > > (pas de view, pas de trigger, pas de procédures stoquées, > > tables de 2Go max, Les views ne servent à rien. Ben voyon, c'est bien connu, les vues on été créées juste pour le fun. elles servent à développer des applis propres sans répéter les clauses where jointive partout ce qui permet d'avoir une appli maintenable et évolutive. Si vous ne savez pas ce que vous faites et que vous vous en servez comme d\'une table c\'est dramatique pour la performance parce que pas d\'indexes. Sous quel sgbd svp? Nous tournons sous informix et oracle et les index des tables sont bien heureusement utilisées par les vues qui en découlent. Les triggers peuvent servir pour faire du delete en cascade, c'est effectivement une très mauvaise utilisation des triggers mais il vaut mieux effacer les tables référencées à la main pour contrôler et optimiser ce qui se passe, ils peuvent vérifier que des clés externes existent pour des inserts et des updates et pour vérifier qu\'on n\'efface pas des trucs référencés par un delete. Ca rame, beaucoup d\'accès disque pour vérifier des conditions que votre application devrait faire. tout ceci est géré par les foreign keys qui n'existent pas non plus en MySQL un autre manque que j'avais oublié ! La limite est passée de 2 à 4 Go depuis la 3.21, puis à 63 bits sur le format MyISAM, par défaut en 3.23. Encore faut-il que l\'OS supporte des fichiers plus gros que 4 Go. Ce qui n'est pas le cas de nos os de prod (Mandrake 7.1) 4 Go sont de toutes façon insuffisant, le concepte même d'une table limitée à un seul fichier pose un problème de fiabilité dans tout environnement de production. C\'est vrai que les procédure stockées peuvent être pratique, mais c\'est pas indispensable. pratique et même très utiles si l'appli doit être modulaire et maintenable. sourceforge marche avec MySQL, je ne dirais pas que leurs besoins sont très limités. Enfin, si vous êtes feignants, que vous n\'avez pas d\'expérience en SQL au-delà de vos cours théoriques sur la troisième forme normale et que le temps de réponse n\'est pas un problème pour vous (rapport de 10 dans un article de ZDNet au début de cette année), vous pouvez toujours voir PostgreSQL. lent, dur à configurer, je ne le recommande pas à qqun d'inexpérimenté. C\'est plus riche fonctionnellement, c\'est vrai que sur MySQL il n\'y a pas de fonction pour transformer un cercle en dodécagone (non c\'est pas une blague, c\'est bien dans PostgreSQL) oui, le catalogue des fonctions est assez impressionant, mais Postgres est surtout un joujou universitaire, une sorte de SGBD labo expérimental. Bon, allez, un vrai problème de MySQL : il gère mal les locks et il y a des problèmes de scalability avec beaucoup d\'utilisateurs et si la base est souvent accédée en écriture et en lecture. Les limites précédentes ne nous ont pas engagé à pousser les tests aussi loin. mais l'info est bonne à prendre. Alain Sébastien. =?iso-8859-1?Q?$RFC822.eml?=
[Confirme] Re: [Confirme] Réf. : Re: [Confirme] Re: Corporate Server [Hors Sujet SGBD]
Tu trouve vraiment postgres difficile à configurer par rapport à Oracle ? j'ai eu l'occasion de manier les deux et postgres est vraiement simplissime à installer à coté d'oracle. Bien que postgres ait des origines universitaires, il a aujourd'hui un développement très actif, et est utilisé dans de nombreux environements de production. Je ne pense pas qu'on puisse le qualifier de "joujou universitaire expérimental" (bien que ce fut le cas au départ). cyril - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 01, 2000 12:06 PM Subject: [Confirme] Réf. : Re: [Confirme] Re: Corporate Server [Hors Sujet SGBD] Sous quel sgbd svp? Nous tournons sous informix et oracle et les index des tables sont bien heureusement utilisées par les vues qui en découlent. Les triggers peuvent servir pour faire du delete en cascade, c'est effectivement une très mauvaise utilisation des triggers Enfin, si vous êtes feignants, que vous n\'avez pas d\'expérience en SQL au-delà de vos cours théoriques sur la troisième forme normale et que le temps de réponse n\'est pas un problème pour vous (rapport de 10 dans un article de ZDNet au début de cette année), vous pouvez toujours voir PostgreSQL. lent, dur à configurer, je ne le recommande pas à qqun d'inexpérimenté. C\'est plus riche fonctionnellement, c\'est vrai que sur MySQL il n\'y a pas de fonction pour transformer un cercle en dodécagone (non c\'est pas une blague, c\'est bien dans PostgreSQL) oui, le catalogue des fonctions est assez impressionant, mais Postgres est surtout un joujou universitaire, une sorte de SGBD labo expérimental.
[Confirme] Réf. : Re: [Confirme] Re: Corporate Server [Hors Sujet SGBD]
Alain Tésio <[EMAIL PROTECTED]>Pour : "[EMAIL PROTECTED]" Envoyé par : <[EMAIL PROTECTED]> confirme-owner@linux-macc : ndrake.com Objet : Re: [Confirme] Re: Corporate Server 16/11/00 00:56 Veuillez répondre à confirme Réponse tardive, pas la pendant 2 demaines. > [EMAIL PROTECTED] a écrit : > > > Le plus gros problème dans le lot, c\'est MySQL: > > il faut vraiment avoir des besoins très limités pour l\'utiliser > > (pas de view, pas de trigger, pas de procédures stoquées, > > tables de 2Go max, Les views ne servent à rien. Ben voyon, c'est bien connu, les vues on été créées juste pour le fun. elles servent à développer des applis propres sans répéter les clauses where jointive partout ce qui permet d'avoir une appli maintenable et évolutive. Si vous ne savez pas ce que vous faites et que vous vous en servez comme d\'une table c\'est dramatique pour la performance parce que pas d\'indexes. Sous quel sgbd svp? Nous tournons sous informix et oracle et les index des tables sont bien heureusement utilisées par les vues qui en découlent. Les triggers peuvent servir pour faire du delete en cascade, c'est effectivement une très mauvaise utilisation des triggers mais il vaut mieux effacer les tables référencées à la main pour contrôler et optimiser ce qui se passe, ils peuvent vérifier que des clés externes existent pour des inserts et des updates et pour vérifier qu\'on n\'efface pas des trucs référencés par un delete. Ca rame, beaucoup d\'accès disque pour vérifier des conditions que votre application devrait faire. tout ceci est géré par les foreign keys qui n'existent pas non plus en MySQL un autre manque que j'avais oublié ! La limite est passée de 2 à 4 Go depuis la 3.21, puis à 63 bits sur le format MyISAM, par défaut en 3.23. Encore faut-il que l\'OS supporte des fichiers plus gros que 4 Go. Ce qui n'est pas le cas de nos os de prod (Mandrake 7.1) 4 Go sont de toutes façon insuffisant, le concepte même d'une table limitée à un seul fichier pose un problème de fiabilité dans tout environnement de production. C\'est vrai que les procédure stockées peuvent être pratique, mais c\'est pas indispensable. pratique et même très utiles si l'appli doit être modulaire et maintenable. sourceforge marche avec MySQL, je ne dirais pas que leurs besoins sont très limités. Enfin, si vous êtes feignants, que vous n\'avez pas d\'expérience en SQL au-delà de vos cours théoriques sur la troisième forme normale et que le temps de réponse n\'est pas un problème pour vous (rapport de 10 dans un article de ZDNet au début de cette année), vous pouvez toujours voir PostgreSQL. lent, dur à configurer, je ne le recommande pas à qqun d'inexpérimenté. C\'est plus riche fonctionnellement, c\'est vrai que sur MySQL il n\'y a pas de fonction pour transformer un cercle en dodécagone (non c\'est pas une blague, c\'est bien dans PostgreSQL) oui, le catalogue des fonctions est assez impressionant, mais Postgres est surtout un joujou universitaire, une sorte de SGBD labo expérimental. Bon, allez, un vrai problème de MySQL : il gère mal les locks et il y a des problèmes de scalability avec beaucoup d\'utilisateurs et si la base est souvent accédée en écriture et en lecture. Les limites précédentes ne nous ont pas engagé à pousser les tests aussi loin. mais l'info est bonne à prendre. Alain Sébastien.
