[Migratation] Application portable, indépendant du SGDB

Bonjour,


Dans le cadre d'un projet de développement de gestion de matière et suivi de process, pour l'ensemble des usines du groupe, nous voudrions développer une application totalement détachée du SGBD utilisé.

Je souhaiterais ainsi prendre contact avec des personnes se posant éventuellement les mêmes questions et critères, pour avancer vers la voie d'une application très flexible, et portable qui plus est.

Un exemple de problème :
Comment gérer les problèmes d'intégrité, si ce n'est par le SGBD lui même, par l'intermédiare des transactions. (existe t'il des transactions dans les normes standards SQL-92, 99, etc ?? ou puis je les obtenir ?)

Bien que nous soyons contre cette idée, pensez vous qu'il serait nécessaire de mettre en place un serveur d'apllication ??

Il n'y à pas de raison de ne pas maintenir l'intégrité dans la base, cf :
http://www.developpez.com/sgbd/cours.htm

Quand à ton architecture, pourquoi ne pas utiliser en effet Java, et un serveur d'applications Java, c'est la mode en ce moment dans les grand comptes...

je sui interréssé par les articles a l'adresse que tu m'a indiqué : "Les B.D Relationnelles Normalisation et SQL ", malheureusement, rien à faire, le pdf ne s'ouvre pas... (?!?)

En fait, le choix de l'outil de développement s'est plutot orienté vers C++ Builder. De plus, je souhaite si possible éviter l'utilisation d'un serveur d'apllication...

Donc, d'après toi, il n'y a pas de problème pour utiliser les transactions, même quand l'application doit fonctionner pour le plus grand nombre possible de SGBD ?

Citation:

---

Donc, d'après toi, il n'y a pas de problème pour utiliser les transactions, même quand l'application doit fonctionner pour le plus grand nombre possible de SGBD ?

---

Il faudra les redéclarer si tu change le SGBD.

Sinon si tu te sert de Borland C++Builder, alors regarde du coté de Datasnap, tu peux déclarer des procédure au niveau de datasnap, ce sera au dessus du SGBD.

Tu as téléchargé C++Builder 6 entreprise éval ? (voirs forum C++Builder).

hum... j'ai justement un petit soucis au niveau de C++Builder 6 et des composants DataSnap, ils n'existent pas dans les librairies portables CLX. Du moins pas encore ??
En effet, je pense qu'il pourrait vraiement être judicieux de dévellopper une application portable windows/linux. ( Nous sommes en se moment en test du beta de KyliX ).
Notre objectif est de pouvoir donner le choix à nos usines de l'OS de l'appli, mais aussi donc de l'OS du serveur de BD. en fait, les usines qui se situent en Ukraine, par exemple, ne veulent pas entendre parler d'autre chose que Windows (SQL Server and Co.), en revanche, en France, tout le monde en a marre de Kcrosoft avec sa politique à la con (ex : ils ont laissé tombé leur maintenance NT, il y moins de 6 mois, or tout ici était basé sur NT... je t'explique pas le bordel et la panique que ca a déclenchée au sein du groupe !)

Bref, il semble que l'heure est aux apllications portables (phase de transition oblige), et indépendante du SGBD...

Mais bon, ca pose, me semble t il, de sérieux problèmes d'intégrité, pas forcément comprise dans les normes SQL (ai-je raison ???)

DataSnap est parfaitement adapté au développement des bases de données en modèle Briefcase, c'est àdire en mode déconnecté.
Indépendamment de la base de données utilisée.
Il est certain que le mode déconnecté est source de difficultés quand les données doivent être synchronisées ou répliquées entre plusieurs clients.
Des bases comme Interbase 6.5 ou SQL Server intègrent des outils de réplication.
Dans tous les cas, les mises à jour vers le serveur sont décidées par l'utilisateur de l'application.

Les composants nécessaires : TClientDataSet, TDataSetProvider, un composant de connexion DataSnap (TCP, SOAP, DCOM, HTTP, CORBA ?), un composant de connexion à la base de données TSQLConnection, et un TSQLQuery pour les requêtes.

Sylvain

Les applications SGBDR totalement portables n'existent pas.

En effet, bien que SQL soit une norme :
SQL : ANSI 1986
SQL 2 : ISO 1992
SQL 3 : ISO 1999
il n'existe aucun SGBDR "commercial" ayant une implémentation qui respecte la norme.
Le seul SGBDR non commercial (expérimental/enseignement) qui implémente la totalité de la norme SQL 3 est Ocelot de Peter Gulutzan.

Pense simplement que, déjà, il n'y a pas de compatibilité des types de donées prévus par la norme et leur implémentation dans les SGBDR les plus courants.
Exemple le type DATE ou TIME ou INTERVAL n'existe pas dans SQL Server.
Le type TIMESTAMP de SQL Server n'a rien à voir avec la norme (il a d'ailleurs été rebaptisé).

Je purrais te donne de multiples exemples d'ordre SQL même apparement très simple qui ne sont pas portable.

predn par exemple la concaténation des chaînes de caractères. D'après la norme c'est ||pour SQL Server et certains SGBDR c'est +...

Tu peux visiter mon site SQLpro sur multimania qui fait un point comparatif de la norme et des principaux SGBDR.

A +