Discussion :

[Jester]

Je viens d'essayer Firebird et je ne suis pas convaincu.

Il m'a déjà fallu un peu de temps pour comprendre que le for update ne sert pas si l'on ne lui ajoute pas with lock.

Le driver JDBC est très limité (pas de batch par exemple).

Il n'a pas voulu de ma table Date (est-ce bien? mal? je ne sais pas trop).

Les performances sont mauvaises. J'ai fait des tests OLTP et OLAP, c'est vraiment mauvais dans les deux cas. Au moins dans le second, ça ne doit pas être la faute du driver JDBC. Quand je dis mauvais c'est entre 2x et 10x plus lents.

J'admets ne pas avoir trop cherché, que ça peut-être sur des points précis, mais ça ne me donne déjà plus trop envie de chercher plus loin.

[VLDG]

Il n'a pas voulu de ma table Date (est-ce bien? mal? je ne sais pas trop).

Moi je viens de créer une table DATE sans problème.

Les performances sont mauvaises. J'ai fait des tests OLTP et OLAP, c'est vraiment mauvais dans les deux cas. Au moins dans le second, ça ne doit pas être la faute du driver JDBC. Quand je dis mauvais c'est entre 2x et 10x plus lents.

Pour tes tests c'est 2 à 10 fois plus lents que quoi ?

sinon, pour faire des tests TPC : tu peux commencer ici http://blog.upscene.com/thomas/index...08&category=19

Personnellement, je n'utilise pas Firebird avec un connecteur JDBC donc je ne peux rien te dire la dessus mais si tu demandes sur le Forum Firebird : certains pourront certainement te répondre....

[Jester]

Amusant, DATE sous isql-fb, ça ne fonctionne pas chez moi.

Pour les perfs, je préfère faire les tests moi-même, ainsi ça prend aussi en compte mes compétences.

Pour mes tests OLAP :

[vanquish]

A mon avis, c'est simplement que les gens qui font le choix de Firebird n'auront jamais besoin de passer a SQL Server (version payante) alors que ceux qui choisissent SQL Server Express devront un jour ou l'autre passer à la caisse

Ce que vous dite est stupide...

Je ne trouve pas.
Ca répond bien à la question initiale, sur les motivations de Microsoft - qui commercialement parlant, sont rarement stupide.

En effet on achète pas un logiciel par ce que c'est gratuit ou payant. On décide d'utiliser tel ou tel logiciel par ce qu'il offre certaines fonctionnalités et que le rapport qualité prix

Tout à fait d'accord sur l'affirmation en général.
Sauf que là on à affaire à 2 produits qui ont un grand nombre de points communs et qui du coup visent plus ou moins la même cible :

- petit groupe de travail (ou site web) avec faible volumétrie,
- gratuité, redristibuabilité (parce que cela participe au cout global, qui lui est toujours un critère important et parfois déterminant).
- plus ou moins auto-administré (tant que l'on reste dans une volumétrie et un pool de connexion restreint)

Donc pourquoi Microsoft paye-t-il de la pub pour sa version gratuite : parce-qu'ils espèrent bien qu'un jour ou l'autre on passe au produit payant.

Soit que, initié à SQL Server à travers la version Express, et que le choix deviennent naturel pour un projet plus important, soit que la base ai atteint 4Go et 1 octet.

Donc si ce que tu dis est vrai, ce que dit VLDG n'est pas stupide pour autant. C'est simplement la définition d'un produit d'appel.

[VLDG]

Amusant, DATE sous isql-fb, ça ne fonctionne pas chez moi.

tu utilises quel dialecte ?

Pour mes tests OLAP

pour tes tests OLAP : tu utilises quelle version de serveur et quelle installation ?
ton processeur est il multi coeur ?

[Jester]

tu utilises quel dialecte ?
pour tes tests OLAP : tu utilises quelle version de serveur et quelle installation ?
ton processeur est il multi coeur ?

Dialecte 3. Je n'ai touché à rien sur une install ubuntu. La version est la super server 2.1.0.17798-0.ds2-1 (la fin peut-être spécifique au package et sans rapport avec firebird). Avec "Date" ça passe, mais ce n'est plus du jeu.
Si je fait un select *, l'erreur est un token unknown pour Date et table unknown pour "Date". Enfin peu importe.

J'ai un bi-core, mais comme il n'y a qu'une requête, un seul core travaille. Avec les autres SGBD c'est pareil.

[VLDG]

la version Classic aurai été mieux.

Pour info : pour faire de l'OLAP, SAS fait des tests avec un fork de Firebirb (Vulcan) dont une partie des sources seront remis dans Firebird 2.5 et Firebird 3.0.

Peux tu me dire ce que tu utilises pour faire tes tests OLAP ?

[Jester]

la version Classic aurai été mieux.

Dans le cas mono connexion, probablement. Mais ça doit peut jouer de toute façon.

Peux tu me dire ce que tu utilises pour faire tes tests OLAP ?

Des requêtes SQL basiques sur un jeu de données simulé.

[chaplin]

Dans le cas mono connexion, probablement. Mais ça doit peut jouer de toute façon.

Dans Firebird, il y a un paramètre qui permet d'enregistrer les données immédiatement sur le disque ou en cache, autrement dit les données sont enregistrés par lots successifs sur le disque. Dans ce cas de figure, les différences de performance sont notables.

En bref, il y a un paramétrage par défaut, et puis le tuning qui permettra d'optimiser les performances.

Faire des comparatifs entre base dépend de pas mal de facteur.

SQLlite est diablement efficace pour des insertions en masse, mais il n'est pas client serveur.

SQL serveur fonctionne sur windows, DB2/400 sur AS400 ou devrais je dire I5, difficile de comparer les deux si ce n'est le rapport performance/prix et encore. Les performances reposent pas seulement sur le SGBDR, il faut tenir compte de l'OS et l'outil de développement utilisé.

[Jester]

Faire des comparatifs entre base dépend de pas mal de facteur.

Certes, j'essaie bien sur d'avoir des configurations similaires notamment sur le commit delay (ce dont tu parles).

On ne peut pas comparer les SGBD en général, mais c'est possible avec des configurations et des cas d'utilisation précis.

[VLDG]

On ne peut pas comparer les SGBD en général, mais c'est possible avec des configurations et des cas d'utilisation précis.

Peut être pour la rapidité mais ce n'est pas le seul choix : autrement ce serait si simple...

I’d argue that Sun needs to tighten the reins on MySQL development, not let them go. Going forward, MySQL will need to work hard if it wants to stay in front of the low-end database business. It’s no longer the reigning speed king; if fast, SQL-based storage is all you care about, SQLite is a better alternative. And competing open source databases like PostgreSQL and Firebird offer better feature sets for exactly the same price as MySQL.

extrait de ça : http://weblog.infoworld.com/fatalexc...shakeup_c.html

[SQLpro]

I’d argue that Sun needs to tighten the reins on MySQL development, not let them go. Going forward, MySQL will need to work hard if it wants to stay in front of the low-end database business. It’s no longer the reigning speed king; if fast, SQL-based storage is all you care about, SQLite is a better alternative. And competing open source databases like PostgreSQL and Firebird offer better feature sets for exactly the same price as MySQL.

Cette citation est tout à fait vraie. Je partage cette analyse et je prédit peu d'avenir à MySQL. A mon sens le seul avantage de MySQL est d'avoir popularisé les bases de données pour des gens qui ne savaient même pas que cela existait.
Mais devant les capacités d'un PostGreSQL ou d'un FireBird, y'a pas photos. Je constate d'ailleurs dans mon boulot beaucoup de passage de MySQL vers PostGreSQL ou SQL Server, avec des applications soit critique, soit demandant trop à MySQL (qui supporte mal la charge).

A +

[Jester]

Je pense qu'un des points forts (en plus d'avoir Sun derrière), c'est l'architecture à plusieurs moteurs de stockage. Ce n'est qu'au début, mais cela me semble prometteur. Je reconnais qu'on peut aussi y voir un point faible à cause de la complexité engendrée.

[VLDG]

Je pense qu'un des points forts (en plus d'avoir Sun derrière), c'est l'architecture à plusieurs moteurs de stockage.

A lire sur MySQL : http://www.developpez.net/forums/d53...r/#post4021819

c'est en effet très prometteur...

si on résume :
Jim Starkey le concepteur de Falcon est parti !

Michael Widenius qui s'occupait de Maria est parti aussi !

Innodb appartient à Oracle !

Il reste quoi ?

[kedare]

Je pense qu'un des points forts (en plus d'avoir Sun derrière), c'est l'architecture à plusieurs moteurs de stockage.

Je trouve que c'est un énorme défaut personellement...
Impossible d'utiliser la recherche fulltext et le transactionnel sur la meme table par exemple....
ca sert a rien a part disperser les features

[Jester]

C'est en effet un des désavantages. Ce sera résolu dans la version 2 de Maria qui sera le remplacement transactionnel de MyIsam.

L'avantage des plugin pour les moteur, c'est bien sur pas trop d'avoir innodb, falcon et maria qui jouent sur le même segment (quoique la concurence sera saine je pense), mais l'apparition de moteurs plus atypiques comme ARCHIVE ou INFOBRIGHT (stockage basé colonnes et non lignes).

Pour l'instant c'est un peu trop tôt, il faut laisser du temps.

[B.AF]

De toutes les façons, il n'y a pas photo pour les applications de gestion aujourd'hui.

Ayant vu globalement tous les produits existant dans des environnemensts en production, le meilleur est DE LOIN est sql server, depuis sa version 2005.

Quand je dis le meilleur, c'est ...
- Le support des charges
- Le coût d'administration
- Les coûts de montée en charge
- le coût d'administration OS et Data
- Productivité des équipes
- Outillage impeccable

Je vais lancer un pavé dans la mare, mais comparer sql server à firebird, c'est une blague.

Firebird pour moi ce sont des moteurs qui gérent finalement des base statiques a faible volume constant.

Mysql c'est sans commentaire pour moi. Enfin non, je suis de l'avis de SQL Pro, ca a démocratisé le SGBD...

Après on peut vouloir croire que l'exotique c'est mieux parce que exotique, mais bon...même oracle, c'est pas un grosse joie de s'en servir quand on sort de SQLS 2008 (qui est un superbe produit).

Je préfére expliquer à mon client qu'il va s'acheter une license et de la tranquilité et qu'il me paye tout les mois sa redevance, que de l'avoir tous les mois au téléphone parce que les perfs sont mauvaises, qu'il faut racheter une machine, que ...

L'équilibre de SQL Server en fait le meilleur SGBD d'entreprise disponible aujourd'hui.
Le problème de sa reconnaissance, c'est qu'il rend inutile des corps entiers d'IT dans les entreprises qui lui trouveront tous les défauts de la terre.

Si je dois redémarrer un nouveau soft demain, ou tout de suite : sql server 2008. Sans me poser de questions.

[qi130]

Ce sont des propos qui n'engagent que toi...

Je ne prêche pas pour ma paroisse, bien entendu

Je raisonne en professionnel, et lorsque je lis une telle prose, je constate une contradiction évidente entre

Ayant vu globalement tous les produits existant

et

le meilleur est DE LOIN est sql server

.

C'est comme affirmer péremptoirement que la meilleure voiture est une Ferrari, sous prétexte qu'on a conduit toutes les autres... Engage toi avec une Ferrari sur le Paris-Dakar, histoire que tout le monde rigole !

Plus concrètement, la litanie des arguments qui rendent, d'après toi, SQL Server meilleur ne tient pas la route...

- Le support des charges ?
Faudrait commencer par préciser ce concept...
Faut-il comprendre forte volumétrie ? Si oui, qu'est-ce qu'une forte volumétrie ?
Ou bien serait-ce un grand nombre d'utilisateurs ? Un grand nombre de requêtes ? Ou encore un obscur melting pot de tout cela ?

- Le coût d'administration ?
Là encore, la précision est de mise... Englobe-t'il la nécessaire formation du personnel qui en a la charge ? Ou bien le coût récurrent du sous-traitant responsable de la chose ?

- Les coûts de montée en charge ?
Qu'est-ce donc ?

- le coût d'administration OS et Data
Là, tu mélanges les choux et les carottes. Ce sont là des métiers différents, et l'administration des datas est normalement réglée au chapitre "coût d'administration". Je n'ose imaginer un DBA faisant abstraction de la typologie des databases lorsqu'il tune le moteur.

- Productivité des équipes ?
Les équipes de quoi ? S'il s'agit des développeurs, la marque du SGBD ne devrait pas rentrer en ligne de compte, sauf à la marge pour quelques finesses SQL propres à ce SGBD.

- Outillage impeccable ?
Sur quels critères ? Ergonomie ? Prise en main (formation obligatoire) ? Installation ? Puissance ? Look ?


Donc, non, SQL Server n'est pas le meilleur SGBD.

Le meilleur SGBD est celui qui correspond le mieux au cahier des charges de l'application qu'il supporte.

Note bien que cependant, je conçois que des intérêts mercantiles te le fassent systématiquement mettre en avant mais c'est un autre débat.

[B.AF]

Un bon SGBD, c'est avant tout une problèmatique de réponse au volume et au nombre de users.

Aujourd'hui, en dehors de considérations de laboratoire, Firebird a chaque fois que je l'ai rencontré en environnement pro, c'était systèmatiquement des problèmes de perfs et de volumes.

Firebird, c'est une base à réserver à des usages à espace connu.

Enfin bon, je sens que là, quand je dis ça, en tant qu'expert Firebird tu le prends comme une attaque perso.

Donc on va rester dans les attaques perso, et moi ça ne m'intéresse pas trop.

Quand on se pose la question dans une entreprise de poser Firebird ou SQL server, honnêtement, il n'y a pas de questions.
Juste de clivages de l'open source alternatif qui prêche sa paroisse.

Je ne vois pas une entreprise choisir de structurer sa donnée d'activité autour d'un SGBD minoritaire et qui plus est concurrencé sur son propre terrains. C'est une choix de geek, pas un choix de raison.

Le simple fait que tu juges que Sql Server coûte plus que Firebird prouve que c'est un exercice qui t'es inconnu.

Déjà :
1 - Les compétences sont faciles à trouver sur SQL server
2 - L'administration est très simple (Va administrer un linux vx.xxxxx avec firebird version binaire z.zz.rrr avec la package tt.g qui est patché...Dans une PME...) --> Je ne vois pas où est le coût de formation...Tu devrais peut être ouvrir SQL Manager 2008 une fois..?
Tu te rendrais compte de la gestion des schémas, l'intellisens pour l'écriture du SQL
3 - Le clustring, la réplication, et autre petites choses sont présentes ET simples
4 - Reporting Services
5 - L'optimiseur est excellent sur SQL Server
6 - Toutes les technos disposent de pilotes efficients sur SQL server
7 - L'administration des shémas de base et des droits et d'une simplicité biblique
8 - Les procédures de backup, c'est aussi biblique (Ca prend approximativement 25 s pour backuper une base...)
9 - Les ponts avec Visual Studio et Team System permettent de créer un vrai suivi d'évolution des shémas

[qi130]

Je crois que tu n'as pas correctement lu ce qui précède...

Malgré les précautions mises en avant

Je ne prêche pas pour ma paroisse, bien entendu
Je raisonne en professionnel

,
tu persistes dans une approche qui me parait très hasardeuse, car trop empreinte de certitudes.

en tant qu'expert Firebird tu le prends comme une attaque perso

Détrompe toi, d'ailleurs un responsable n'est pas forcément un expert

tu juges que Sql Server coûte plus que Firebird

Je te mets au défi de prouver cette affirmation au travers de mes écrits.

prouve que c'est un exercice qui t'es inconnu.

il n'y a rien à prouver, puisque je ne me suis pas risqué sur ce terrain.
De plus, j'ai l'honnêteté de ne pas prétendre pouvoir le faire, au contraire de certains autres.
Au passage, je te demande d'être un peu plus respectueux des compétences des autres, mêmes si elles ne sont pas mises sur la place publique.

En fait, au travers de mes questions (qui sont sans réponse), j'ai tenté de te faire entrevoir certaines approches/méthodes à mettre en oeuvre dès qu'il s'agit de faire un choix.
En vain !

Le problème quand on a les idées bien arrêtées, c'est qu'on a souvent arrêté d'en avoir.

Tu aurais pu relaté ta success story, en précisant le contexte, en fournissant quelques chiffres. Cela aurait été enrichissant.

Mais tu te contentes de casser du Firebird, gratuitement, pour le fun.

Ce n'est ni professionnel, ni constructif.