[Résolu] Choix de base de données

[PlanteG]

Bonjour à tous,

ma question vise tout aussi bien SDK que ODBC, mais comme dans ODBC il a déjà été question de base de données, je présente ma question ici.

Je vais faire du développement de fonctions maisons reliées à Acomba, mais j'ai toutefois besoin de stocker des données ailleurs que dans Acomba. Je considère une solution gratuite, mais ai des hésitations face à ce qui est disponible. Je suis contrôleur de l'entreprise, mais ingénieur en informatique de formation. Voici les produits qui pourraient être utilisés:

SQL Server 2005 Express: je l'ai installé à la maison, mais j'ai des "contres" qui sont les suivants. C'est un produit difficile à administrer pour un non initié. Si je suis absent et qu'un problème survient, je ne vois comment les autres vont se débrouiller. La documentation de MS est so so - je sais que c'est un produit gratuit, mais MS est maître dans l'art de faire des fichiers d'aide et de documentation nébuleux. C'est gros comme tous les produits de MS. Du côté positif, il y a un service 'Reporter', mais je ne suis pas sûr que cela fonctionne avec la version Express.

DB2 Express d'IBM: IBM a aussi son produit express pour suivre la vague. Mais il est dans leur habitude de sortir un produit puis soudainement de le retirer. De plus, trouver de l'information sur leur site est un cauchemard !!!

Oracle 10g Express: Oracle a une bonne réputation, mais du côté de ce produit, je ne sais trop quoi penser. Oracle offre un produit de développement gratos, applications par Web, mais je penses utiliser VS 2005 Express.

De tous les produits Express, un seul offre un produit pour faire des rapports. C'est quand même une partie importante.

Le produit le plus simple d'utilisation est Access. Côté rapports c'est très bon, mais du côté de l'interface, j'ai déjà eu à me battre contre lui, car le fonctionnement des dialogues est différent de ce que l'on voit dans VB et VBA: il y a des contraintes vraiement chi...

Voilà, quelqu'un a des suggestions ?

Merci

[Lartis]

Bonjour,

Il s'agit de préferences personnelles, donc je vous en fait part, mais c'est à prendre sous toute réserve. Je n'ai pas testé tous les produits que vous proposer.

Je crois que vous devriez évaluer individuellement l'hébergement des données et l'interface de développement.

Pour l'hébergement des données, selon le volume de données, la performance requise et la présence d'expert, j'hésiterais entre SQL Server/Oracle et Access. Access étant nettement plus simple à administrer, mais beaucoup moins performant. Je ne connais pas DB2 Express. J'ai mis SQL Server et Oracle sur un pied d'égalité. Je préfère personnellement Oracle pour la plus grande stabilité.

Pour l'interface de développement, encore ici, Access est la solution nettement la plus simple. Il est souvent possible de développer/maintenir avec Access facilement deux fois plus rapidement qu'avec les autres outils de développement comme VB. Avec VC++, c'est généralement encore plus long. Par contre, on gagne au change au niveau de la performance. Donc c'est à voir si vous avez besoin de performance ou de développement/maintenance rapide. Je me suis moi aussi pas mal "battu" avec MSAccess, mais j'ai gagné! J'ai développé des outils qui contournent pas mal tous les irritants que j'ai rencontré. (Entre autre, j'ai développé du code pour que la sauvegarde se fasse sur pression d'un bouton, et non pas automatiquement. Lorsqu'on ferme un formulaire, il demande "Voulez-vous sauvegarder?" et si on répond "non", il annule automatiquement les changements plutôt que de sauver automatiquement)

Personnellement, j'ai fait des solutions très efficaces en n'utilisant qu'Access. Mais il s'agit de solution avec peu d'usagers, et pour lesquels la rapidité n'était pas un critère majeur.

Petit commentaire consernant SDK versus ODBC: à mon avis, pour la majorité des projets, le temps gagné en développant avec l'ODBC surpasse son coût de façon significative. Donc à moins qu'il s'agisse d'un petit projet, ça vaut la peine de penser fonctionner par ODBC.

[PlanteG]

Merci Lartis pour la réponse. Voici des commentaires sur celle-ci:

Je préfère personnellement Oracle pour la plus grande stabilité. Voilà un point intéressant. Je veux éviter au maximum les pannes qui pourraient se pointer lorsque je suis absent.

Vos remarques sur l'interface d'Access sont en plein dans le mille. Ce qui me fait hésiter à utiliser Access comme une simple interface est sa pauvreté au niveau des contrôles, Visual Studio est beaucoup plus riche à ce niveau, et le "cannage" général au niveau de l'interface qui limite passablement les possibilités.

Effectivement, ODBC simplifie passablement la vie du développeur.

[Lartis]

Bonjour,

SQL Server est lui aussi très stable, mais j'aurais quand même une légère préférence pour Oracle. (mais je le redis, je ne connais pas la version gratuite d'Oracle)

Pour Access, il est souvent possible de trouver des ActiveX qui complètent les fonctionnalités manquantes. Entre autre, j'ai déjà travaillé avec des composents FTP et Zip très faciles à utiliser.

Lorsque vous parlez de pauvreté au niveau des contrôles, vous parlez de quoi plus précisément? Si c'est un problème que j'ai déjà rencontré, je peux peut-être vous donner des façon de contourner le problème.

Une des lacunes d'Access est au niveau de son interface usager par défaut (avec l'accès aux tables, requêtes et formulaires, avec les menus par défauts), mais il est tout à fait possible d'en faire une application blindée. J'ai fait plusieurs applications avec des menus custom, et empêchant complètement l'accès à l'interface normal. Un fois qu'on sait comment faire, le résultat peut ressembler assez à une application VB. La seule limitation vraiment difficile à contourner, c'est la sécurité. Avec Access, il est très difficile de vraiment protéger le code. Il existe des programmes pour trouver le mot de passe et même pour décompiler les .mde. La seule façon vraiment sécuritaire que j'ai trouvé, c'est de mettre le code dans une DLL externe compilée en VB ou C++. Mais c'est quand même assez complèxe, et ça protège le code, mais pas les données.

[PlanteG]

Sylvain,

Lorsque vous parlez de pauvreté au niveau des contrôles, vous parlez de quoi plus précisément?

Je pense ici aux termes Anglais "controls", comme "list box", "text box", "Grid" etc., bref les types d'objets qui composent l'interface.

Une des lacunes d'Access est au niveau de son interface usager par défaut (avec l'accès aux tables, requêtes et formulaires, avec les menus par défauts), mais il est tout à fait possible d'en faire une application blindée.

Il est important d'offir aux utilisateurs une interface simple à utiliser. L'interface d'Access est conçue pour manipuler des données dans une BD à sa plus simple expression. Les fenêtres à l'écran sont des formulaires, bien accrochés à une source de données, et non pas des dialogues comme en VB par exemple. Dès que l'on essaie de sortir de ce modèle, on a de sérieux problèmes. Et j'ai sué un bon coup pour apprendre cela. De plus, les applications Access prennent beaucoup d'espace à l'écran. Ce à quoi je pense est un dialogue avec des onglets et l'utilisation de grilles du gener MSFlexGrid. Et je veux déterminer la navigation par moi-même, sans me faire imposer la façon à la Access !

Côté protection du code, c'est effectivement très so so.

[Contenu sponsorisé]