Discussion :

[khena]

Par exemple le SQL n'est pas 100% identique d'une BDD à l'autre, chacune ayant malheureusement ses petites spécificités.

Le premier cas qui me vient à l'esprit, c'est le magnifique code SQL "INSERT OR UPDATE"' des dernières versions de Firebird... Bonjour le gain de temps en développement ! Par contre, ce n'est possible que si les composonts "suivent" Firebird (ce qui n'est pas le cas des IBX par exemple).

Pour Francis, il faut répondre à cet algo

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
IF SGBD imposé par le client
THEN Pas le choix
ELSE IF multi SGBD (maintenant ou dans l'avenir)
        THEN BEGIN
                categorie := BDE LIKE;
                CASE priorité OF
                  performances : produit := UNIDAC;
                  pérennité : produit := OleDB (Ado ou DBX intégré à Delphi)
                  duree du dev : Zeos  
                 end
               END
         ELSE BEGIN
                categorie := compo dédiés;
                CASE priorite OF
                 simple : produit := IBX;
                 gratuit mais sans doc: produit := UIB;
                 payant mais avec support produit := FibPlus;
                end;
         END

Bien sur c'est simplifié, mais je pense qu'il y a toujours un moyen de se débrouiller dans le cas où le choix du composant ne permet pas certaines choses (compatibilité du reporting, exportation des données, etc.)

La plus grosse partie du boulot, c'est l'utilisation quotidienne de ces composants, donc vaut mieux se faire chier sur des détails peu fréquents, que de se faire chier tout le temps en voulant tout gérer!

Philippe > j'ai cherché de la doc pour les UIB, mais à part le forum, y a-t-il une descriptif des objets et composants ?

[makowski]

Philippe > j'ai cherché de la doc pour les UIB, mais à part le forum, y a-t-il une descriptif des objets et composants ?

la source et les exemples et le readme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

svn co https://uib.svn.sourceforge.net/svnroot/uib/trunk

[Franck SORIANO]

Sous Windows exclusivement oui
mais rien ne t'empèche d'utiliser OLEDB pour te connecter à Firebird

On est sur un forum Delphi. Tant que mes appli Delphi ne tourneront que sous Windows, je ne vois pas l'intérêt de me préoccuper des APIs des autres OS

Petite question : OLEDB est livré en standard avec l'installation Windows de FireBird, ou bien est-ce qu'il faut passer par un provider OLEDB tiers et payant ?
Parce que personnellement, je me vois mal dire à un client à qui j'ai vendu FireBird avec l'argument "c'est libre, c'est gratuit, c'est ouvert", que s'il veut s'en servir avec ses appli, il doit acheter un driver propriétaire et fermé...

Rien à voir avec la choucroute
Delphi est un outil propriétaire qui choisit selon ces version d'intégrer tel ou tel outil ou composant
Rien n'empèche les editeurs de Delphi de livrer en standard quelque soit les versions un connecteur de leur choix à Firebird.
Il se trouve juste que dans le passé (avant Embarcadero) l'éditeur de Delphi avait manifestement sciemment fait le choix de ne pas permettre facilement en standard l'accès à Firebird.

Mais là on parle de Delphi, avec d'autres langages le problème ne se pose même pas.

Je crois qu'on n'a pas la même conception de ce qu'est un standard en termes de développement.
Pour moi, on définit une API standardisée (en l'occurence OLEDB sous Windows), puis chaque fournisseur de SGBD doit te fournir avec son SGBD les drivers qui implémentent l'API standard. Il peut proposer également une API propriétaire (au sens qui ne respecte pas le standard) mais ce n'est qu'un plus.
De leur côté, les outils de développements se doivent de fournir le nécessaire à l'utilisation de ces API standards. Delphi doit fournir un moyen d'utiliser un pilote OLEDB (tu en as quatre : ADO (directement), dbGO (encapsulation de ADO), Dbx (indirectement pour certains pilotes), ou directement les interfaces COM (c'est ce que je fait)), mais ne doit pas avoir à se préoccuper de tous les SGBD existants sur le marché.
Pour moi, ce n'est pas CodeGear qui a fait de la résistance envers FireBird, c'est FireBird qui s'est tiré une balle dans le pied en n'implémentant pas le standard !
Les standards servent à ça : Permettre à deux partis qui s'ignorent de travailler malgré tout ensemble !

- tout le reste, le pire étant les perfs !

Détrompe toi, c'est avec OLEDB que les perfs sont les meilleures ! (avec un provider correct bien sûr).
C'est l'empilement de couches que tu ajoutes au dessus (ADO, dbGO, Dbx, ClientDataSet...) qui dégrade les perfs.

Par exemple, avec OLEDB, j'arrive sans problèmes à faire un select qui retourne 440 lignes en 4 ms : http://fsoriano.developpez.com/artic.../oledb/delphi/ (à la fin).
Et encore dans cet exemple, je passe toujours par un TDataSet. Or ce dernier est lui-même une grosse source de ralentissement. En faisant la lecture directe, je peux charger les données en deux fois moins de temps !

Au passage, je suppose que tu dois travailler avec des PME spécialisées dans l'informatique, parce que des entreprises de 10 personnes qui ont le temps de s'occuper du choix du SGBD de leur outil informatique... ouah

Je fait de la paie (avant je bossais pour les concessionnaires automobiles, la concession ne comprenait peut-être pas tout, mais le constructeur leur imposait un minimum de standards).
Une société de moins de 10 salariés, c'est une TPE.
Celles ci font faire leur paie par un Expert Comptable, elles n'ont pas besoin d'un SGBD pour 10 salariés, au mieux on leur propose du Cloud ou de faire leur paie à leur place sur des offres de service.
Pour les TPE, on cherchera plutôt à vendre nos services à l'Expert.
Mais les entreprises de 20 à 100 salariés commencent à avoir une véritable infrastructure informatique.

[khena]

Effectivement, je ne pensais pas que les perfs étaient si bonnes avec OleDB.
Toutes mes confuses!

Cependant, pour des raisons de temps de développement, je pense que beaucoup de gens utilisent ce fameux empilement de couches, qui ajoute à la complexité et qui ralentissent les perfs de base.

Dans tous les cas, il est évident que Francis doit d'abord choisir son SGBD avant de penser aux composants à utiliser... L'intérêt de l'utilisation du couple IB(FB) et Delphi est justement l'intégration simple de la connexion et l'interrogation du SGBD depuis Delphi.

Il serait intéressant de créer un sondage sur les composants utilisés pour se connecter aux principales SGBD depuis Delphi.

[makowski]

Effectivement, je ne pensais pas que les perfs étaient si bonnes avec OleDB..

En fait tout simplement parce que c'est biaisé
OleDB est le pilote natif pour SQLServeur
mais pas pour les autres SGBD
pour les autres, c'est une couche en plus.

quand au "standard" livré par le projet Firebird pour Windows, c'est l'API en C++ ou le pilote dotNet ou le pilote Java ou le pilote Python ou le pilote Odbc.

Le reste est en dehors du projet, mais on peux considérer UIB comme un bon "pilote" pour Delphi.


Dire qu'OleDB est un standard c'est comme dire que Itunes est un standard pour acceder aux IPod .

Et si quelqu'un veux utiliser OleDB pour travailler avec Firebird, il peut.

[Franck SORIANO]

En fait tout simplement parce que c'est biaisé
OleDB est le pilote natif pour SQLServeur
mais pas pour les autres SGBD
pour les autres, c'est une couche en plus.

C'est faux. Sur les versions récentes, le pilote natif pour SQL Server, c'est SQL Native Client.
Historiquement, c'était même plutôt la DBLib, c'est à dire une DLL totalement propriétaire qui ne suivait aucun standard...

OleDb n'est pas un pilote, c'est la spécification d'un ensemble d'interfaces que chaque fournisseur peut/doit implémenter.
Elle permet d'accéder à un SGBDR, mais pas seulement.
Microsoft a implémenté OLEDB pour SQL Server et fournis un pilote OLEDB performant. Mais il existe encore plus performant (pour SQL Server) : ADO.NET.

Chacun est libre de l'implémenter comme bon lui semble (surcouche ou implémentation du protocole réseau). Les choix d'implémentation auront bien sûr un impact certain sur les performances. Mais OLEDB n'a pas plus de raison d'être une surcouche par dessus autre chose qu'un pilote JDBC sous Java, ou qu'un fournisseur ADO.NET.

quand au "standard" livré par le projet Firebird pour Windows, c'est l'API en C++ ou le pilote dotNet ou le pilote Java ou le pilote Python ou le pilote Odbc.

Merci pour l'info .

Dire qu'OleDB est un standard c'est comme dire que Itunes est un standard pour acceder aux IPod .

Je crois que tu confonds [ame="http://fr.wikipedia.org/wiki/Standard"]standard [/ame] et norme.
Un standard, c'est ce qui est le plus largement répandu.
De facto, il existe des standards de droit, qui font l'objet d'une norme et des standards de fait, qui bien que non normalisés sont le plus répandu, ne serait-ce que parce que leur auteur détient un quasi monopole !

[SergioMaster]

1- Pour faire bien et avoir plus de chance de vendre le progi, la solution Sql Server fournit plus d'atouts commerciaux

Oui si on en reste a Microsoft, Oui pour des entreprises disposant des moyens financiers nécessaires . Comme l'a dit un autre intervenant je ne vois pas une PME de 10 à 15 salariés prendre un DB opérateur , enfin tout dépend bien sur de la PME etc...

2- FireBird nécessite des composants Tiers si on veut faire correctement les choses ce qui nous rend notre appli dépendante de l'évolution de ces composants

Je dirais: "pas plus que les évolutions de DELPHI". Quelque part c'est le même problème

Et si je voulais développer mon appli Multi SGBD, comme ça chacun aura pour son argent. Quelle serait l'approche. Si quelqu'un s'est attaqué à ce problème, son avis serait le bienvenu.

Je me suis un peu attaqué à MySQL (apres tout elle semble être la plus répandue sur le WEB , beaucoup la considérant +ou- a tort comme gratuite) sans grande conviction , mais c'est possible .


Outre les différences entre SGBD déjà citées , le choix devrait se faire en fonction des bases proposées par les composants Tiers (je considére DBExpress comme un Tiers fourni Avec Delphi

Au risque de me répéter c'est encore un choix Couts/moyens/Compétences/Temps qui doit être la base de la réflexion . le critère argument commercial est a prendre en compte bien sur mais un bon commercial peut vendre la Lune c'est au technicien d'aller la décrocher !
On rajoutera donc un individu , ce qui donne
Couts/Moyens/Compétences/Temps/Cible ,

te voilà déjà 5 axes certains étant de graduation facile , A toi le bonheur des graphiques 'radars' dits encore toiles d'araignée


D'expérience

pour l'utilisation de Firebird il faut soit Delphi2010 entreprise soit utiliser des compos tiers . Dans le 1°cas 2271 € (1450 € upgrade) dans le second
457€ + 200 ou 0 dépendant des composants . Nota ceci ne prend pas en compte le nombre de développeurs .

ZEOS : Temps d'adaptation à partir d'un existant BDE/Firebird PO (plutôt minime voir 0) cout 0
DBExpress (aucune idée , j'ai jamais accroché le wagon , je trouvais à l'époque la pose de pas moins de 4 composants pour une table absurde , mon poil dans la main qui parle, bref je n'ai jamais reussi mon adaptation , je suis passé par D1,D3 le +gros du dev ,D4,D5..D7)

UIB cout 0 , temps d'adaptation du personnel , j'évaluerai a une 10 de jours pour faire le tour des problèmes du au ReadOnly et BigdataSet
FIBplus cout , voir plus haut dans le comparatif , adaptation du personnel 5 à 10 jours
ces deux derniers ne sont pas Multibase

je ne regarde même pas la différence cout client

[Francis]

Franck SORIANO _________________
Mes articles : http://fsoriano.developpez.com/
Le tracing avec Event Tracing for Windows (ETW)

J'ai parcouru l'un de vos articles. ça m'a rappelé mes premiers programmes écrits en assembleur il y a quelques décennies.
C'est sûr que si on descend à ce niveau , on a des performances.
Mais, nous perdons la puissance de Delphi, pour écrire rapidement des trucs assez complexes. En plus pour faire de la mise à jour ça ne va pas être de la tarte.
Je vous remercie tous pour votre intéressante participation à ce débat et propose avec votre accord de clore ce sujet.

Un expert est généralement quelqu'un qui vous explique quelque chose que vous savez déjà...

[Franck SORIANO]

C'est sûr que si on descend à ce niveau , on a des performances.
Mais, nous perdons la puissance de Delphi, pour écrire rapidement des trucs assez complexes. En plus pour faire de la mise à jour ça ne va pas être de la tarte.

Pas vraiment. Après tu poses ton framework applicatif par dessus et tout ce fait très facilement.
En fait, je réimplémente la couche d'accès aux données standard de Delphi.
Le code que je donne est une illustration de comment utiliser la techno. Mais celui que j'utilise réellement est beaucoup plus élaboré.
Je réécris le composant TTable et TQuery (en ajoutant la facilité OpenSQL et ExecSQL).
Au final, le compilateur et les développeurs ne voient pas la différence et continuent à coder comme ils avaient l'habitude en Paradox. Sauf qu'en interne, je gère les données radicalement différemment.
Ca nous permet d'être multi-SGBD, l'équipe de dev n'a pas réellement besoin de s'adapter aux nouveaux SGBD. Et on obtient malgré tout de bonnes performances (même si en supprimant le TDataSet ça pourrait être bien, bien mieux...).

[khena]

Effectivement Franck, ce que tu proposes c'est très bien, mais je vois que tu es déjà toi-même en amont de l'équipe de développement, ce qui te permets d'anticiper les migrations et de maintenir ton package à jour. Pour une petite équipe, ça me semble difficile à réaliser.

Je vais essayer de reprendre cette discussion et de la mettre en forme pour faire un comparatif des composants les plus connus de connexion Firebird pour Delphi. Il est temps de mettre à jour le site !