IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Bases de données Delphi Discussion :

Migration de BDE vers Firebird


Sujet :

Bases de données Delphi

  1. #21
    Membre régulier
    Inscrit en
    Avril 2002
    Messages
    94
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 94
    Points : 73
    Points
    73
    Par défaut
    Khena je te remercie pour ces informations détaillées et claire.
    Après ces débats forts intéressants, sachant que je viens du BDE et je veux migrer vers FB, quelle est la solution la plus fiable en terme d'accès concurrentiels, la plus rapide à mettre en œuvre et la plus performante en terme de temps de réponse.
    Merci par avance.

  2. #22
    Expert éminent
    Avatar de Lung
    Profil pro
    Analyste-programmeur
    Inscrit en
    Mai 2002
    Messages
    2 663
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Analyste-programmeur
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 663
    Points : 6 949
    Points
    6 949
    Par défaut
    Citation Envoyé par SergioMaster Voir le message
    @Khena pour le DBExpress Firebird ne pas oublier d'indiquer D2010 Architect
    Et avec D2010 Entreprise, ca ne marche pas ?
    Pourtant, il y a les compsants DBExpress, non ?
    (j'ai encore rien testé)
    L'urgent est fait, l'impossible est en cours, pour les miracles prévoir un délai. ___ Écrivez dans un français correct !!

    C++Builder 5 - Delphi 6#2 Entreprise - Delphi 2007 Entreprise - Delphi 2010 Architecte - Delphi XE Entreprise - Delphi XE7 Entreprise - Delphi 10 Entreprise - Delphi 10.3.2 Entreprise - Delphi 10.4.2 Entreprise
    OpenGL 2.1 - Oracle 10g - Paradox - Interbase (XE) - PostgreSQL (11.6 - 14.6)

  3. #23
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    Citation Envoyé par Francis Voir le message
    Khena je te remercie pour ces informations détaillées et claire.
    Après ces débats forts intéressants, sachant que je viens du BDE et je veux migrer vers FB, quelle est la solution la plus fiable en terme d'accès concurrentiels, la plus rapide à mettre en œuvre et la plus performante en terme de temps de réponse.
    Merci par avance.
    A priori UIB ou FIBPlus
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  4. #24
    Membre régulier
    Profil pro
    Chef de projet en SSII
    Inscrit en
    Février 2003
    Messages
    59
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2003
    Messages : 59
    Points : 93
    Points
    93
    Par défaut
    Citation Envoyé par Lung Voir le message
    Et avec D2010 Entreprise, ca ne marche pas ?
    Pourtant, il y a les compsants DBExpress, non ?
    (j'ai encore rien testé)

    Je viens de contrôler sur le site de Codegear, effectivement, c'est à partir de la version Entreprise. Sergio >

    Francis, si c'est un produit perso, je dirais UIB.
    Si c'est pro et que les délais sont courts, là c'est plus difficile
    ++ khena
    Rien n'est plus beau q'une clé,
    Tant qu'on ne sait pas ce qu'elle ouvre.

  5. #25
    Membre confirmé Avatar de TryExceptEnd
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Octobre 2006
    Messages
    501
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2006
    Messages : 501
    Points : 574
    Points
    574
    Par défaut
    Le résultat d'une migration une application tournant sous BDE vers Firebird ne seras jamais satisfaisant en l'état. Je vous conseil plutôt de réécrire votre application en ne gardant que les Forms et Unités qui peuvent être réutilsées sans soucis ou avec quelques aménagements.
    D'après mon expérience, cela vous prendras un certain temps (8-12 mois) mais le résultat serait beaucoup plus abouti et beaucoup plus pérenne.
    Moi, j'ai fait cette migration il y a trois ans et j'ai utilisé les composants UIB plus les composants GrizzlyPack pour ses Datasets en mémoire et cela sans aucun problème.
    Si vous êtes libre, choisissez le Logiciel Libre.

  6. #26
    Membre régulier
    Inscrit en
    Avril 2002
    Messages
    94
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 94
    Points : 73
    Points
    73
    Par défaut
    Citation Envoyé par TryExceptEnd
    Francis, si c'est un produit perso, je dirais UIB.
    Si c'est pro et que les délais sont courts, là c'est plus difficile
    C'est Pro et le problème le plus important que j'ai laissé pour la fin est qu'il y a que du Quick Report!
    N'y a-t-il pas un moyen d'utiliser les Ttables en les dérivant ou autre chose pour réimplémenter les méthodes du type FindKey et autre?

  7. #27
    Modérateur
    Avatar de Rayek
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mars 2005
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 5 235
    Points : 8 504
    Points
    8 504
    Par défaut
    Le plus fiable serait de laisser tomber les FindKey & Co et de passer au SQL et procédures stockées qui seront largement plus fiable et rapide que de tenter de dériver des composants pour avoir le même effet que le BDE.
    Modérateur Delphi

    Le guide du bon forumeur :
    __________
    Rayek World : Youtube Facebook

  8. #28
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    Citation Envoyé par khena Voir le message
    Je viens de contrôler sur le site de Codegear, effectivement, c'est à partir de la version Entreprise. Sergio >
    méa culpa , je n'arrive jamais a savoir lequel est le plus bas entreprise ou architect n'empêche que j'enrage que cela ne soit pas déjà en pro

    Citation Envoyé par makoski
    A priori UIB ou FIBPlus
    je "plussoi"

    Citation Envoyé par Francis
    N'y a-t-il pas un moyen d'utiliser les Ttables en les dérivant ou autre chose pour réimplémenter les méthodes du type FindKey et autre?
    Quand je disais que les habitudes de BDE sont difficiles a perdre ...
    d'ou la suggestion de migration douce avec ZEOS (même avec ses bugs ) et ses locates

    Citation Envoyé par Francis
    le problème le plus important que j'ai laissé pour la fin est qu'il y a que du Quick Report!
    oui , ça n'arrange pas

    Citation Envoyé par rayek
    Le plus fiable serait de laisser tomber les FindKey & Co et de passer au SQL et procédures stockées qui seront largement plus fiable et rapide
    Absolument-à-l'eau

    Le tout reste bien un problème de temps et moyens $$$$
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  9. #29
    Membre régulier
    Inscrit en
    Avril 2002
    Messages
    94
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 94
    Points : 73
    Points
    73
    Par défaut
    En définitive, il est devenu clair que le mieux est de tout reprendre. Dans ce cas pourquoi ne pas opter pour une Base de Données Sql Server?
    Qu'en pensez-vous messieurs?

  10. #30
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 021
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 67
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 021
    Points : 40 935
    Points
    40 935
    Billets dans le blog
    62
    Par défaut
    changer de SGBDR c'est un tout autre débat !
    Par contre tout reprendre est une alternative . Je le répète c'est une question cout/moyens/compétences (idem pour la BDD d'ailleurs)
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  11. #31
    Membre régulier
    Profil pro
    Chef de projet en SSII
    Inscrit en
    Février 2003
    Messages
    59
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2003
    Messages : 59
    Points : 93
    Points
    93
    Par défaut
    Avec Delphi et les composants que nous avons cité ci-dessus, je pense que Firebird reste le top des SGBD

    Je plussois aussi pour UIB ou FIBPlus, ainsi que pour la réécriture du code.

    Pour QuickReport, il ne faut pas trop se faire de soucis, il utilise tous les héritiers du TDataset
    ++ khena
    Rien n'est plus beau q'une clé,
    Tant qu'on ne sait pas ce qu'elle ouvre.

  12. #32
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Points : 4 170
    Points
    4 170
    Par défaut
    Citation Envoyé par Francis Voir le message
    En définitive, il est devenu clair que le mieux est de tout reprendre. Dans ce cas pourquoi ne pas opter pour une Base de Données Sql Server?
    Qu'en pensez-vous messieurs?
    C'est à toi de voir en fonction du contexte et du cas de figure où tu te trouves.

    Si tu es éditeur de logiciel, dire à tes clients que ton appli tourne sous SQL Server sera perçu comme un gage de qualité :
    - Ils connaitront probablement déjà le nom et sauront que c'est un SGBD fiable, reconnu et pérenne.
    - Tu peux passer un royalty agreement avec Microsoft qui te permettra de revendre SQL Server intégré à ton application. Tu auras un SQL Server complet, sans aucunes limitations, à un prix largement de nature à concurrencer du gratuit. Par contre, tes clients n'auront pas le droit de s'en servir en dehors de ton application (plus exactement, ils n'auront pas le droit de créer de nouvelles base, ni de nouvelles table dans tes bases).
    - SQL Server est accessible via des API STANDARD d'accès aux données (OLEDB, ADO, ODBC...). Tu n'auras pas besoin de passer par des composants tiers.
    - D'autres applications pourrons accéder directement à ta base (par exemple reporting Excel....). Tu seras ainsi assuré de pouvoir utiliser n'importe quel outil de reporting, de Data mining, de réplication...
    - SQL Server est très largement répendu. Le support, les docs et les formations ne manquent pas...
    - SQL Server est capable de s'adapter à toutes les volumétries : Allant de la base de données embarquée (avec SQL Server Compact) à de très grosses volumétries digne d'un Datacenter. C'est également un des SGBD les plus performant qui soit.

    Essaie de parler de FireBird au client lambda : Tu as de grandes chances qu'il te regarde avec de grands yeux en te disant "c'est quoi ça ?" et tu perds l'avantage de la notoriété de Microsoft.

    Personnellement, je ne me pose pas question :
    - Je fait mes devs pour SQL Server, et Oracle lorsque je n'ai pas le choix.

    Si par contre, ton appli est distinée à un dev interne, il vaut que tu choisisses le SGBD en fonction de ton environnement de production et de ce que vous serez capable de maintenir et d'administrer le plus facilement. Donc de l'environnement que vous maîtriser le mieux.

  13. #33
    Membre régulier
    Profil pro
    Chef de projet en SSII
    Inscrit en
    Février 2003
    Messages
    59
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2003
    Messages : 59
    Points : 93
    Points
    93
    Par défaut
    On s'éloigne un peu du sujet, mais personnellement quand je fais des offres, mes clients n'ont pas à savoir la base de données que j'utilise. Dans les contrats, les clients sont propriétaires des données, que je dois mettre à leur disposition si jamais ils décident de me "virer". La plupart du temps, cette mise à disposition se fait sous fichier Excel.
    Parce que si je commence à leur parler de la base de données, on est pas sorti, vu le nombre de SGBD disponibles, dur de se justifier. Déjà qu'ils ont du mal à comprendre l'informatique...

    Mais bref...

    Je cherche toujours ce paquet de composants BDE Like qui traine quelque part. Je l'ai déjà vu sur ce forum, j'ai déjà vu le site, mais impossible de revenir dessus. C'est dingue ça. Je sais que c'était un paquet qui existait pour VS .NET et pour Delphi, et que ça gérait pleins de SGBD, dont Firebird.

    Si quelqu'un a pu tester les IBDAC , j'aimerai bien avoir un retour dessus aussi!
    ++ khena
    Rien n'est plus beau q'une clé,
    Tant qu'on ne sait pas ce qu'elle ouvre.

  14. #34
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Points : 4 170
    Points
    4 170
    Par défaut
    Citation Envoyé par khena Voir le message
    On s'éloigne un peu du sujet, mais personnellement quand je fais des offres, mes clients n'ont pas à savoir la base de données que j'utilise.
    Pas vraiment puisque le PO a demandé notre avis sur le choix de SQL Server !

    Pour ce qui est de "les clients n'ont pas à savoir la base de données", ça dépend des clients.

    Je suis également en plein déploiement d'une migration BDE -> SQL Server/ Oracle et je peux te dire que nos clients (principalement des PME de 10 à 100 salariés) nous reprochaient d'être en Paradox, et nous demandent quel SGBD on utilise.
    Nos études de marché montraient également que l'appli ne serait pas vendable en progi si elle ne tournait pas sous SQL Server (et la Production pour nos usage interne refusait de l'héberger si elle n'était pas sous Oracle).

    Dès que ton client à une taille suffisante pour lui demander d'installer un serveur de données, il se préoccupe de l'impacte que ça va avoir sur son réseau. Des problèmes de sécurités potentiel, d'administration du serveur, ce que ça va lui apporter et s'il ne peut pas mutualiser avec d'autres applications...
    Et il n'y a pas besoin que le client soit très gros pour que toutes ces questions commencent à arriver. Ceux qui ne nous posent pas ces questions sont aussi ceux qui ne voient pas l'intérêt de migrer et veulent rester sous Paradox.

    Il n'y a vraiment que si tu installes du monoposte que le client ne cherche pas trop à savoir comment tu vas polluer sa machine.

    Dans les contrats, les clients sont propriétaires des données, que je dois mettre à leur disposition si jamais ils décident de me "virer". La plupart du temps, cette mise à disposition se fait sous fichier Excel.
    En informatique de gestion, les clients sont très très sensibles au reporting. Ils sont prêts à payer des fortunes aussi importantes que la licence de l'appli elle même pour un malheureux état de gestion qu'on peut réaliser en trois requêtes SQL.
    Ce n'est pas pour rien si la BI se vend aussi cher, alors qu'il n'y a en fait pas grand chose derrière (comparé à l'appli de gestion complète).

    Quand tu peux dire à un décideur que la base de donnée est standard et ouverte, que s'il ne trouve pas son bonheur dans les indicateurs fournis en standard par ton appli, il pourra toujours se faire son propre tableau sous Excel : Ca va le rassurer.
    Si en plus tes concurrents ont une solution basée sur un SGBD exotique et qu'ils n'ont pas cette possiblitée, ça te donne un avantage certain, même si ta licence est plus onéreuse.

    Ensuite évidemment tout le monde n'a pas les mêmes besoins. C'est pourquoi il faut choisir son SGBD en fonction de son contexte d'utilisation.
    L'informatique, c'est bien plus qu'un choix technique !

    Je cherche toujours ce paquet de composants BDE Like qui traine quelque part. Je l'ai déjà vu sur ce forum, j'ai déjà vu le site, mais impossible de revenir dessus. C'est dingue ça. Je sais que c'était un paquet qui existait pour VS .NET et pour Delphi, et que ça gérait pleins de SGBD, dont Firebird.
    Moi j'ai développé les miens. C'est ce qui nous permet d'avoir les mêmes sources pour maintenir l'appli legacy en Paradox, la nouvelle version Progi en SQL Server, et la version hébergée sous Oracle.

    Maintenant on peut aussi utiliser l'architecture préconisée par Embarcadero : TClientDataSet + TDataSetProvider + TSqlDataSet + Drivers DBExpress.

    Les performances ne sont pas vraiment au rendez-vous, mais le clientdataset est pas loin d'être 100% compatible avec le TTable du BDE, ce qui limite l'effort de migration.

  15. #35
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    Citation Envoyé par Franck SORIANO Voir le message
    Quand tu peux dire à un décideur que la base de donnée est standard et ouverte,
    soit exactement le contraire de ce qu'est un logiciel privateur comme SQL Serveur


    et je passe sur tes précédents arguments qui sont loin d'être spécifique MSSQL
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  16. #36
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Points : 4 170
    Points
    4 170
    Par défaut
    Citation Envoyé par makowski Voir le message
    Quand tu peux dire à un décideur que la base de donnée est standard et ouverte,
    soit exactement le contraire de ce qu'est un logiciel privateur comme SQL Serveur
    C'est vrai que quand on ne cite que la moitié de la phrase et qu'on la sort de son contexte, ça ne veut plus dire grand chose .
    Ca veut donc dire que je me suis mal exprimé :
    Lorsque je dis "la base de donnée est standard et ouverte", je ne parle pas du SGBD (ça n'a dailleurs aucun sens), ni de la définition que les libristes donnent au mot "ouvert". Je parle de connectivité, par opposition au stockage dans des fichiers propriétaires que seule l'application qui les a générées est capable de relire. Je ne compte plus le nombre de migrations que j'ai dû effectuer où le seul moyen d'extraire les données était d'imprimer des listes sur une matricielle, en redirigeant la sortie de l'imprimante dans un fichier (parfois en bricolant un cable série, ou un cable croisé). Et je ne parle pas des éditeurs concurrents qui nous ont généreusement fournis la description des enregistrements de leur fichiers COBOL en nous disant : "On vous les donne parce qu'on sait très bien que vous n'avez aucun moyen de lire les fichiers".

    Certes, c'est que propose normalement tout SGBD digne de ce nom. Mais encore faut-il pouvoir s'y connecter facilement.

    Sous Windows, il existe UN standard pour la connectivité à une base de données : il s'agit de OLEDB, sur lequel s'appuie ADO (et même Dbx pour certains SGBD), ODBC étant déprécié depuis au moins 20 ans.

    Si ta base de données est accessible via OLEDB, le client à l'assurance de pouvoir accéder à ses données avec les outils de son choix sans être obligatoirement contraint de passer par ton appli.
    Il lui suffira d'avoir les comptes de connexion.

    Lorsque ta base de données est sous Paradox par exemple, il n'y a que le BDE qui sache relire toutes les tables correctement, sans perdre les BLOB ni les accents.

    Je dois dire que je suis vraiment surpris de voir qu'il faut encore se poser la question de savoir quels composants utilisés pour accéder à FireBird.
    Lorsque je vois qu'il faut passer par des composants tiers, souvent payants, je trouve que c'est un comble pour un SGBD qui se veux "libre, ouvert et gratuit".
    Sans parler du fait que passer par des composants spécifiques (je ne vais pas dire propriétaire ), est un obstacle au développement d'applications multi-SGBD.

    et je passe sur tes précédents arguments qui sont loin d'être spécifique MSSQL
    Je n'ai jamais dit que c'était une exclusivité SQL Server
    Mais encore une fois, je rappelle que le PO a demandé un avis sur SQL Server, je donne mon avis sur SQL Server

  17. #37
    Membre régulier
    Profil pro
    Chef de projet en SSII
    Inscrit en
    Février 2003
    Messages
    59
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Février 2003
    Messages : 59
    Points : 93
    Points
    93
    Par défaut
    Je pense qu'il ne faut pas se tromper de débat. Chacun trouvera l'utilité de composants spécifiques (ou pas) et de base de données "connues" ou pas selon son cas.

    Franck, si je prends ton exemple, effectivement je comprends tes choix : tes clients sont demandeurs d'une technologie reconnue et utilisé et tu attaques de multiples bases de données : il est évident que les compo Firebird ne sont pas adaptés à ta situation.
    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

    Pour revenir sur le standard OLEDB (ADO ou DBX), pour moi qui n'utilise QUE Firebird, nous avons longtemps eu un débat là dessus :

    * Soit nous développons avec des compo. dédiés à Firebird (tels UIB, IBX ou FIBplus) :
    + le développement est plus aisé (quand je vois le nombre de composants et de ligne de code pour gérer les transactions avec DBX... huhu !)
    + les compo. sont "dédiés" aux fonctionnalités de la BDD (exemple : composant backup / restore intégré)
    + la maintenance est plus aisée
    + performances au top
    - si un jour, on doit changer ou attaquer un autre SGBD, c'est la merde !

    * Soit des compos génériques, que j'appelerais (en hommage ) BDE Like:
    + Les compo ne dépendant pas du SGBD, donc migration plus facile
    + Pérennité
    - tout le reste, le pire étant les perfs !

    Je pense qu'il est très difficile pour des "petites" structures de décider du choix à adopter. L'anticipation sur des projets importants est primordiale. Donc, la priorité à donner aux choix des composants dépendra de la capacité de l'équipe de dév. à analyser les forces en présence et à venir.
    ++ khena
    Rien n'est plus beau q'une clé,
    Tant qu'on ne sait pas ce qu'elle ouvre.

  18. #38
    Membre régulier
    Inscrit en
    Avril 2002
    Messages
    94
    Détails du profil
    Informations forums :
    Inscription : Avril 2002
    Messages : 94
    Points : 73
    Points
    73
    Par défaut
    Ce débat devient intéressant, mais aucune solution n'émerge.
    Donc je résume.
    1- Pour faire bien et avoir plus de chance de vendre le progi, la solution Sql Server fournit plus d'atouts commerciaux
    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
    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.

  19. #39
    Membre émérite
    Avatar de skywaukers
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Juin 2005
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Charente (Poitou Charente)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 215
    Points : 2 303
    Points
    2 303
    Par défaut
    Bonjour,

    Citation Envoyé par Francis Voir le message
    1- Pour faire bien et avoir plus de chance de vendre le progi, la solution Sql Server fournit plus d'atouts commerciaux
    Comme le dit Khena, cela dépend avant tout de la cible de ton application. Si elle est destinée à une entreprise du domaine de l'informatique comprenant des techniciens avec des avis définis sur les technos alors cela peut influencer ton choix de BDD (et pas forcément dans le sens SQL Server d'ailleurs).
    Si elle est destinée à une PME d'un autre domaine alors leur préoccupation ne sera surement pas trop le tampon qu'il y a sur la BDD, mais plutôt la performance, la fiabilité, le coût de maintenance car il y a très peu de chance qu'il possède un DBA. Ils voudront aussi être sûr de ne perdre aucune données.
    Après il y a le problème du reporting, il peut effectivement y avoir chez eux aussi des utilisateurs un peu plus pointus qui ont une utilisation poussée d'Excel par exemple et qui seront bien évidement très intéressés par la possibilité d'accéder aux données autrement que par une boite noire que représente une application pour eux. Pour cela il est important que la base de données puisse être accessible via OLEDB, mais ça n'oblige nullement ton application à passer par là pour s'y connecter.

    Citation Envoyé par Francis Voir le message
    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
    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.
    Le multi DB va faire apparaître des problèmes autres que le simple choix du framework d'accès. Par exemple le SQL n'est pas 100% identique d'une BDD à l'autre, chacune ayant malheureusement ses petites spécificités. donc la première chose à faire, c'est de se contraindre à n'utiliser que le dénnominateur commun dont on est sûr qu'il va passer partout. Ensuite soit tu choisis une couche d'accès qui soit la plus répandue possible (OLEDB semble être un bon choix, mais en prenant soin de tester tout de même les comportements sur chaque cible), soit tu te fais une couche d'abstraction par dessus qui te permet de développer sans te soucier du mode de connexion à la base de données. Bien sûr dans ce cas là il faudra certainement bannir les automatismes puisque souvent liés aux composants utilisés. L'avantage c'est que ça te permet ensuite à moindre coût de prendre les meilleurs composants d'accès pour chaque base de données ciblée.

    @++
    Dany

  20. #40
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    Mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 2 342
    Points : 3 712
    Points
    3 712
    Par défaut
    Citation Envoyé par Franck SORIANO Voir le message
    Sous Windows, il existe UN standard pour la connectivité à une base de données : il s'agit de OLEDB
    Sous Windows exclusivement oui
    mais rien ne t'empèche d'utiliser OLEDB pour te connecter à Firebird
    Citation Envoyé par Franck SORIANO Voir le message
    Je dois dire que je suis vraiment surpris de voir qu'il faut encore se poser la question de savoir quels composants utilisés pour accéder à FireBird.
    C'est juste qu'on a le choix,
    Citation Envoyé par Franck SORIANO Voir le message
    Lorsque je vois qu'il faut passer par des composants tiers, souvent payants, je trouve que c'est un comble pour un SGBD qui se veux "libre, ouvert et gratuit".
    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.
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

Discussions similaires

  1. [EJB3 Entity] Migration MySQL vers Firebird
    Par Mister Nono dans le forum Java EE
    Réponses: 0
    Dernier message: 23/12/2008, 20h51
  2. Migration Oracle vers fireBird
    Par ensisoft dans le forum Firebird
    Réponses: 4
    Dernier message: 08/10/2007, 23h54
  3. Migration BDE vers DBExpress sur firebird
    Par olivier_nicollet dans le forum Connexion aux bases de données
    Réponses: 4
    Dernier message: 17/07/2007, 11h02
  4. [IBX] migration paradox vers firebird : Comment fonctionne TIBTable ?
    Par Benjamin GAGNEUX dans le forum Bases de données
    Réponses: 3
    Dernier message: 07/07/2006, 11h22
  5. Migration Paradox vers Firebird 1.5
    Par breiz35 dans le forum Débuter
    Réponses: 11
    Dernier message: 15/03/2006, 13h06

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo