Procédures stocké et compatibilité entre SGDBRésolu

Question

Bonjour ,

Je développe actuellement un logiciel de gestion de données (le détail de l'appli n'apporte pas grand chose à mes questions je pense). Problème il faut que ce programme puisse se connecté à tout type de SGBD (tout du moins à tout SGBD poste 1995, soit un peut plus de 10 ans, je peut re-limité légèrement ce choix). Du coup en final je me retrouve (pour évité de surcharger le réseau) à développe deux application : un serveur (se connecte en local au SGBD, fait les traitements et calculs), un client (qui se connecte à l'appli serveur, affiche les données et retransmet les actions utilisateur).

Si possible je voudrais (par l'intermédiaire de procédure stocké) m'affranchir de l'appli serveur. Suite à quelque recherche je remarque que les procédures stockées écrite en SQL n'ont pas la même syntaxe suivant les SGBD . Mais j'ai crue également voire qu'une procédure stocké peut s'écrire en C  (et sa c'est bien). Dans ce cas la syntaxe devrais être le même sur tout les SGBD (soit la syntaxe du C, forcément ). A condition que ce SGBD supporte les procédures stockées en C bien sure (il y en à beaucoup qui ne le supporte pas ?).
(Question 1 :) Je me trompe ?

Heeeeeeee , par contre je n'es fait que TRÈS peut de procédure stocké (et jamais en C) dans ma pitite vie de programmeur.
(Question 2 :) Comment je fait ? Je transmet directement une dll déjà compilé, ou le code programme en C et le SGBD le compil (à moin que je n'es le choix) ?
(Question 3 :) Pourriez-vous me donnée un lient vers un tuto ou un exemple de création de procédure stocké en C.

Merci par avance 

Amicalement 
Pensez "Réponse acceptée"

nhervagault · Accepted Answer

Pour moi tu es sur une fausse piste.

Tu n'a pas besoin de faire de serveur, si tes clients lourd peuvent se connectée directement à la base de données.
Il suffit que ta couche d'abstraction de base de données soit dans le code source de ton appli cliente.

Le top c'est de faire ton appli serveur en WCF (service web ou autre) .
Apres l'architecture dépend des réels besoins de ton application et de son oiuverture (intranet/extranet/firewall)

De toute facon dans la solution que tu présente c'est le client qui appel en directe les procedures stockées.
A la place il devrait appellé des webservices qui appel soit des proc stocks soit des requetes directe (plus portable cf lien MSDN plus haut) 

HIBERNATE et les autre outil de mapping sont basés sur ce principe
utilisatation de dialectes propres a chaque base pour créer des requetes dynamiques.

nhervagault · Answer

Salut,

Je pense que tu es sur une mauvaise piste,
les procédures stokée ont un langage différent selon les bases de données

exemple 
Oracle (java, PL/SQL,C,Cobol, ..)
DB2 (COBOL,C,SQL PL , java?,....)
SQLServeur (TSQL, C#, VB.Net)
MYSQL (nouveautés)

Donc il y a de compatibilité entre les différentes bases aux niveaux procedures stockées
Il faut sinon ecrire les procedures stockées dans chaque langage

Tu peux faire que de la compatibilité au niveau SQL, il faut que les types soit en SQL 92 ou plus
Avec ADO.NET tu peux normalement gérer une abstraction.

http://msdn.microsoft.com/fr-fr/library/bb469872.aspx

Polack77 · Answer

Merci pour ta réponse 
Donc pas possible de faire ce que je veut .... Pas glop 

Heeeeeeeee  pas contre je n'es pas compris un truc :
Tu dit :
8<-----------------
Oracle (java, PL/SQL,C,Cobol, ..)
DB2 (COBOL,C,SQL PL , java?,....)
SQLServeur (TSQL, C#, VB.Net)
MYSQL (nouveautés)
----------------->8

Dans la liste que tu me donne je vois que le C est compatible avec : Oracle, DB2, SQLServeur (le C# reste compatible avec le C, comme le C++ à sont époque, enfin je crois  ).

La syntaxe est différente suivant les types de SGBD, même en C 

(Je peut interdire l'utilisation de MySQL sans problèmes en cas de besoin)

Amicalement 
Pensez "Réponse acceptée"

nhervagault · Answer

Non c# est un langage basé sur le framework dotnet donc pas du tout compatible avec du C.
C c'est procédural, C# c'est objet

Et les API sont payantes sur les bases de données et leur API (interface de programmation différentes)

Et tres peu de documentation, meme c'est peu etre plus utilisé ???

En général, les procédures sont écrites dans un langae natif pour :
1-->Gagner en performance (plus proche de la base de données)
2-->Etre dans un langage compilé et non interprété (plus rapide)
3-->Fonction lente ou inexistante (chaine de caractere, regexp)

Tu perds ton temps a chercher de ce coté-ci désolé.

Polack77 · Answer

Désolé d'être chiant, mais si j'arrivais quand même à le faire sa me ferais gagné en temps FOUT donc je cherche quand même encore un peut   :

En effet je viens de vérifier le C# n'est pas tout à fait compatible avec le C "classique" mais on doit pouvoir faire des fonctions/procédures qui fonctionneront en C et en C# (à moins que mon idéalisme est encore pris le dessus ).

Exemple :
   En C :
      int a[5];
   En C# :
      int[] a = new int[5];

   Mais sa, sa devrais être bon en C comme en C# :
      int* a;
      a = malloc(sizeof(int) * 5);

(Ok c'est pas top propre, et il faut IMPERATIVEMENT pensé au "free(a)". Mais sa reste plus rapide que de lancé mes traitements en SQL (SQL92 en plus) )

Dernière question :
Une procédure stocké écrite en C "classique" devrais au minimum compatible entre Oracle et DB2 ? A moins que les types ne change, et alors là,  c'est foutu  (encore que par allocation dynamique en utilisant des sizeof...).

PS : Malgré mon apparente insistance je commence à pensé qu'il vaut mieux que je fasse mon appli client serveur. Sa me feras perdre du temps mais bon, si il faut le faire  (au faite merci pour le lient msdn  )

Amicalement 
Pensez "Réponse acceptée"

Polack77 · Answer

Oui mes clients peuvent se connecté directement à la base.

Le problème vient de l'occupation du réseau. Je fait des gros calcul (sur environ 20 000 ligne de la base à chaque fois) pour sortir en final une petite dizaine de résultat en long et string, 200 oct max par couple string long, donc 2 ko ~ de données à exploité alors qu'il faut 1 000 foix plus (à la louche) pour calculé ces valeurs (calcul ne se fessant en prime pas toujours sur les même lignes de la base, de plus la base complétte est relativement grosse ~ 150 000 lignes, donc pas de mode déconnectée)

Le coup des web services est une bonne idée. Je pense je vais regarder de ce coté 

Merci du temps investie à mon problème 

Amicalement 
Pensez "Réponse acceptée"

nhervagault · Answer

C'est pas des gros volumes 20 000 lignes de base de données
les bases de données savent gérer sans problèmes.

Tu as trois solutions : 
--> Soit faire les calculs sur la base procédures stockées
--> Soit dans un programme type webservice (20 000 en entrées --> 10 lignes en sorties) 
--> Soit sur le client meme chose que sur le webservice (mais plus de circulation réseu) quoique le webservice peut etre sur une autre machine que la base -> revient au même qu'avec un client (un peu plus verbeux car comm reseau ws client en plus)

Il y a peu etre possibilité de faire des vues pour préfiltrer  tes lignes avant tes calculs --> moins de traitements 
et plus optimisé. 

Je ne pense pas que le volume indiqué est vraiement la source du problème. 
Quand on voit le poids des page html > 60 ko sans les images c'est rapide afficher.
A moins que tu es sur de l'embarqué.
Le problème vient surement  que ta base n'est pas bien optimisée (pas d'index, ....) ou que tes requetes sont mal faites.

Polack77 · Answer

Non non, en final le vrais problème vient du réseau de mon client (encore en base 10 et déjà plusieurs application réseau qui font que sa raaaaaaaaaaaaaaaaaaaaaaame).

Je pense gardé la solution du WCF 

Merci pour ces précisions 

Amicalement 
Pensez "Réponse acceptée"

Procédures stocké et compatibilité entre SGDB

8 réponses

Votre réponse

Discussions similaires