Quel est le meilleur moyen d’accéder à une base de données ?

[aityahia]

D’après votre expérience quel est le moyen le plus efficient pour accéder à divers base de données je ne parle pas des composants dédiés tel que ceux d’interbase, avec un commentaire justifiant votre choix sera appréciable.
Quand je parle efficience c’est un moyen qui allie efficacité, rapidité et simplicité d’utilisation.
Je vous remercie d’avance pour votre contribution.

[Kaféine]

salut moi je dispose d'une couche d'abstraction qui me permet de switcher de bdd sans toucher a mon code.

[SergioMaster]

Oui je sais c'est totalement obsolète , mais j'ai commencé au tout début de DELPHI et au départ j'étais bien content de le trouver . J'ai des applis complexe de 10 ans qui tournent encore chez des utilisateurs , et sans bobos

Bien sur maintenant j'utilise FIB+ plus rapide, plus fiable mais plus complexe
alors pour un débutant c'est le bon choix
après bien sur faut évoluer

[aityahia]

Bon moi j'ai voté ADO je peux dire que je suis satisfait mais pas pleinement j’ai plusieurs bug que je n’arrive pas a comprendre et que je contourne avec du code qui n’est pas forcément nécessaire
Exemple
Avec Access :
J’ai toujours le message « l’enregistrement n’a pas été trouvez pour la mise a jour, c’est possible qu’il soi Modifier depuis le dernier enregistrement » ce message survient lorsque j’essai de modifier un enregistrement fraichement ajouter.
Sous SQL Serveur j’ai le message « EoleException une erreur inconnue s’est produite » lorsque j’exécute sous l’IDE et pas quand je le fait à l’extérieur.
Tous ces ambigüités mon poussé a posté ce sondage et pour essayer de voir plus loin que le bout de mon nez.

[evarisnea]

je n'ai pas voté, car je ne comprend pas la question.
telle que tu l'as posée, moi je répondrais que le meilleur moyen d'accéder à une bd, en terme de vitesse et de performances, c'est l'utilisation des drivers natifs pour la bd en question mais en terme de simplicité je ne sais pas si c'est applicable.

Envoyé par Kaféine

salut moi je dispose d'une couche d'abstraction qui me permet de switcher de bdd sans toucher a mon code.

ça m'intéresserait bien de savoir comment tu procèdes. est ce performant ?

[aityahia]

Envoyé par evarisnea

je n'ai pas voté, car je ne comprend pas la question.?

Désolé si ma question n'est pas claire mais ce que je voudrai savoir, c'est quel sont les composants qui assure une meilleure prise en charge des drivers et fluide comiunication entre mon interface et ma base de données.

[napz]

j'ai voté ado , j'ai débuté comme tout le monde en bde, puis j'ai adobté l'ado , j'ataque mes bases assez souvent en ODBC ,access et ms-sql oblige, mais je prévois d'allé voir d'autre sieul dans le monde des BD

[philnext]

Bon ... ADO pour moi.
Aucun bug.
Pour la notion de 'couche d'abstraction' c'est généralement une interface entre le code et la base de données qui permet de se libérer des contraintes liées à chaque base. Par exemple ça peut servir à interpréter les requètes SQL car chaque base à des syntaxes un peu différentes.
Généralement il n'y a pas de raison que ça ralentisse (ni que ça accélère).
Le BDE peut être considéré comme une 'couche d'abstraction'.

[aityahia]

je vous remercie tous pour vos votes, je vois que ADO prend d'éja de l'avance c'est qui est bon signe pour moi puisque je travail avec

[fthdz]

bonjour

j'ai voté pour ADO que je retrouve tres simple dans l'utilisation en plus il donne plusieurs choix pour le paramétrage, concernant les performances !! il faut voir les gens qui utlisent des milions d'enregistrements.

mais des fois je suis obligé d'utiliser le BDE dans les cas des tables DBF.
merci

[Bloon]

Envoyé par aityahia

D’après votre expérience quel est le moyen le plus efficient pour accéder à divers base de données je ne parle pas des composants dédiés tel que ceux d’interbase, avec un commentaire justifiant votre choix sera appréciable.
Quand je parle efficience c’est un moyen qui allie efficacité, rapidité et simplicité d’utilisation.
Je vous remercie d’avance pour votre contribution.

Dommage car le meilleur moyen d'accéder aux données, c'est justement d'utiliser des composants natifs Si tu as besoin d'accéder à plusieurs sgbd, il faut développer une couche d'abstraction comme l'a dit philnext.

Sinon pour répondre à ton sondage, ADO me semble être le meilleur choix.

Bloon

[franck SEFIC]

J'utilise ADO avec sql sever. C'est comme si j'etais en natif. Pas besoin meme de gérer les transactions par code.

[Sub0]

Salut!

J'ai voté «Autres». J'ai commencé la programmation SGBD avec MySQL pour des sites web en PHP, et lorsque j'ai voulu utiliser Delphi (6 perso) pour effectuer des requêtes sur ces bases, je n'ai pas trouvé de composants satisfaisants (compatibilité, facilité d'installation, sécurité, fiabilité, etc).

La solution que j'ai adopté est d'utiliser des scripts PHP sécurisés via des requêtes Http1.0. Il ya un certain nombre d'avantages à cette solution. Cela me convient parfaitement pour le moment. J'ai écri un 1er tutoriel sur ce projet, je suis maintenant en train d'ajouter de nouvelles fonctionalités à ce projet. D'ailleurs, si vous avez des questions, des remarques, des suggestions, je suis à votre disposition.

Interaction entre Delphi et PHP -> DELPHP

[aityahia]

après 4 Jours de sondage ADO prend de l'avance a 66 % par apport aux autres réunis et les résultat sont les suivant

• 10 Votes ADO
• 2 Votes BDE
• 1 Votes DbEpress
• 2 Votes pour les autres moyens

pourquoi ADO, Pourquoi DbExpress des petits comentaire pour les votes

[dd_garion]

Je vote DBExpress qui est vraiment très performant...
MAIS
ADO l'est tout autant donc, pour moi, les deux se valent.

Ce que je peux dire, c'est que je ne voterai certainement pas pour BDE, bien qu'il ai rendu pas mal de service par le passé, il est quand même voué à disparaître...

[aityahia]

Envoyé par dd_garion

Ce que je peux dire, c'est que je ne voterai certainement pas pour BDE, bien qu'il ai rendu pas mal de service par le passé, il est quand même voué à disparaître...

je te remercie pour ton vote,effectivement le BDE nous a rendu pas mal de services mais a l'époque on avez pas vraiment le choix le seul moyen qu'offre Borland pour un accès aux données jusqu'à la version 3 de delphi si je me souviens bien, en plus Borland a abandonner le développement de son produit au détriment des autres outils tel que ADO

[ProgD]

a mon avis chaque objet de connexion à une base de donnée à des avantages et des inconveignans seulon le type de base de données ou l'on voeux se connecter, chaque composant est une force de métriser un type de pase de donnée.
Par Exemple
pour paradox il est plus simple d'utilisés les objet BDE.
pour Acces ADO.
Pour Inter Base objet InterBase
ect...
mais parfois certain programmeur ont une préférence seulon leurs connaisssance et leurs expérience, dans le guide du développeur de Delphi, disent que les objet ado sont exactement similaire aux composant ensemble de donnée utilisant le BDE, d'ailleur ils ont la même classe TdataSet comme ancêtre commun de ce fait ils partages des fonctionnalité communes dans des propriété et méthodes et hévenement hérités.
mais en ma connaissance l'objet le plus choisis par les programmeur est ADO.
pa seulemon par sa puissance mais surtout car il permet de se connecter à plusieur type de base de données sans pour autant changer à chaque fois le code source du programme.
alors J'opte pour ADO mois aussi.

[aityahia]

je remercie tous ceux qui ont participés aux votes
0
ADO est incontéstablement le meilleur moyen utilisé pour ce connecté au base de données non FireBird et Interbase avec ces 16 voix sur 25 , j'ai pu esayer SQL Server avec le pilote SQL Native Client c'est le couple parfait

[WolffN]

ton sondage n'a rien a voir avec firebird ni interbase

il parle de couche d'abstraction d'acces aux donnees firebird,interbase,sql serveur et dans une moindre mesure acces sont des serveurs de bases de données

d'ailleurs il y manque une option => composants permettant l'acces direct a la base de données

si tu souhaite utiliser ADO avec firebird tu n'as qu'essayer de passer par un driver ODBC

mais je t'assure que les composants permettant d'acceder directement aux bases seront bien plus efficaces que de passer par ADO

c'est logique plus tu vas rajouter d'intermediaire plus le traitement global de transition des requetes/resultats sera long

[ShaiLeTroll]

J'ai voté Autre, car j'utilise MyDAC pour MySQl en ce moment, j'ai souffert avec du MK Query sur Oracle et SQL Server ... mais aussi le BDE (j'aime tant Paradox), j'ai eu aussi ma mauvaise expérience IB due à ma méconnaissance de certaines astuces (prepare explicite car sinon chaque open le refait ... grrr ...) dans les Compo IB ... j'ai vu un jour l'onglet DB Express, aucune idéee comment ça fonctionne, et pour ADO, pire, la seule fois que je l'ai eu, c'était des versions modifiées (une pour ORACLE, MS SQL Server, FireBird) par le précédent programmeur du projet qui n'avait pas eu l'idée de laisser ses commentaires dans ses versions alternatives d'ADO (il avait foutu des modifs PassThrough dans tous les sens genre des bouts de compo accès natif), de Dream Script, de son propre Memory Manager, et autres trucs en ASM dont je pigeais pas un mnémonique ... mais sinon pour avoir vu nombreux débats à ce sujet, je dirais que ADO remporte la mise

Sinon, ayant fait 2 ans d'indus, ce que je préfère c'est le Dump Mémoire, tu as tout dans une zone mémoire, que tu lit/écrit dans un thread, et que tu dump cycliquement dans un autre thread ... performant incroyable, durée des données quasi nulles (bon faut dire que si le programme plante, les données qui seraient dans une table sont fausse puisque ne représente plus l'état du robot ... donc inutile ), et prise de tête pour faire en sorte que le dump ne se fasse que lorsque tu n'as plus de lecture/écriture ou gérer par secteur (souvent par enregistrement du tableau) lorsque tu as quand même des données persistantes ... ah oui, j'oubliais, le SQL ça me gave ... c'est pour cela que j'aime les trucs à la con que l'on fait en indus ... et ça fait 4 ans que je ne fais plus que de l'info de Gestion, mais pourquoi le monde est-il si cruel ...