Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: Compatibilité MySQL [ Répondre ] Par : M Jung on 2015-04-30 17:07 | [forum:482931] |
|
Hello Cyril, Personnellement, je préfère HSQLDB (HyperSQL) à MySQL, son installation est d'une simplicité qui laisse rêveur... elle permet de faire très facilement de l'embarqué, du in-memory etc... en portabilité c'est le nirvana : à condition d'avoir une JVM qui tourne sur la plate-forme... MySQL, PG SQL ne peuvent pas en dire autant. Question performances, c'est du Top !. Mais bon après ça, chacun ses goûts et ses couleurs.. Pour ce qui est de la couche d'abstraction, je te donnes 100% raison : c'est en effet "La Solution" qui permettait de connecter le code de l'application à n'importe quelle RDBMS (ou presque...) ; en règle général, je fais du développement en Java avec Hibernate comme couche d'abstraction ; c'est assez difficile au début, - la doc n'est pas géniale pour apprendre, mais au bout de quelques mois de pratique on s'y fait et on y prend même plaisir, tellement les choses en deviennent simples. En ce qui concerne Variation, j'ai eu l'occasion de mettre mon nez dans le code (c'est OpenSource, alors tant qu'à faire...) au moment d'étudier les possibilités d'importation des données d'une autre Gestion d'usagers ; comme le précise Sébastien Kicin, il y a effectivement beaucoup de requêtes PL/SQL appelées à partir de code php, voire js (apparemment JQuery) ; dans le code php et js je ne trouve pas de vrai SQL, mis à part quelques petites requêtes dans la partie webdav. Au moment de l'installation, je me suis rendu compte qu'elle ne fonctionnait pas avec n'importe quelle version de Postgresql, mais seulement à partir de la 9.x (j'étais sur du Fedora 14 qui est livré avec du PG 8.x) et c'est là que j'ai découvert l'utilisation INTENSIVE de requêtes PL/SQL que je n'avais jusqu'à présent jamais utilisées (je suis de la vieille école, du presque début d'Oracle = SQL*PLus v 2.0 ......) pour la simple raison que je n'en ai jamais eu besoin, - probablement j'essaie de respecter les règles de conception MERISE des bases de données relationnelles. Et c'est là que le bât blesse. L'aspect "adaptabilité" de la solution Variation, entraîne aussi des inconvénients (invisibles pour l'utilisateur final), - en tout cas à cause de la façon dont la base a été conçue : tous les champs de l'entité "Usagers" peuvent être créés selon les besoins de chaque contexte, c'est à dire que je (l'utilisateur final) pourrais créer un champ nommé STARWARS, format varchar, longueur x .. si besoin. Super, à priori. Concrètement, cela a été traduit dans la base par une table "personnes" qui contient les Usagers (entre autres) sous forme de per_id (unique) et le type de personne (ent_code) toutes les autres champs concernant l'Usager sont déclarées dynamiquement via une table qui contient per_id et un nom de données (libre) le tout avec une clé unique appelée pin_id qui elle-même foreign-key dans l'une des 5 tables destinées à contenir, des champs de type varchar, boolean, integer, text, ou dates... dans le cas du champ STARTWARS, on obtient une ligne dans la table contenant les varchar avec une clé unique, notre foreign-key pin_id et des dates de début/fin validité ... Bref, ceci a pour conséquence que pour récupérer les données tels que le nom, le prénom, la date de naissance etc ... je me dois d'exécuter une requête pour trouver le nom de l'usager, (je stocke le retour) une autre pour le prénom (que je stocke) et ainsi de suite jusqu'à ce que j'ai récupéré tous les champs concernant l'usager et c'est seulement là que je peux par exemple les afficher : dans mon cas, un usager se défini comme suit (44 champs) : donc 44 requêtes (sans compter celles qui servent à trouver la correspondance avec les entiers qui pointent vers des Listes, ni celles qui permettent de déterminer quelle table je choisi d'interroger pour tel ou tel type de données (dans la partie meta, je crois). D'où l'origine, - à mon avis, de l'utilisation de PL/SQL qui permet de "simuler" l'exécution d'une seule requête par l'appel d'une procédure qui en réalité regroupe plus de 50 requêtes (si tout était fait à partir de php, bonjour le code) Conclusion : impossible d'utiliser une couche d'abstraction ADO si de toute façon je ne fais pas de SQL dans mon code php ou js. pin_id per_id inf_code 4343 423 nom 4344 423 prenom 4345 423 statut_usager 4346 423 origine_placement 4347 423 problematique 4348 423 numero_securite_sociale 4349 423 validite_de_couverture 4350 423 sexe 4351 423 nationalite_actuelle 4352 423 nationalite_d_origine 4353 423 date_naissance 4354 423 lieu_de_naissance 4355 423 famille 4356 423 date_prochain_projet 4357 423 date_projet 4358 423 projet_objectifs 4359 423 projet_moyens 4360 423 numero_dossier_prise_en_charge 4361 423 langue_maternelle 4362 423 niveau_de_francais 4363 423 regime_alimentaire 4364 423 action_educative 4365 423 urgence_placement 4366 423 ordonnance_45 4367 423 mineur_etranger_isole 4377 423 type_de_formation 4378 423 niveau_de_formation 4395 423 contact_pedagogie 4397 423 contact_pedagogique_interne 4398 423 contact_pedagogique_externe 4399 423 notes_pedagogiques 4402 423 referent 4403 423 referent_1 4404 423 contact_social 4405 423 contact_judiciaire 4406 423 placement_anterieur 10475 423 medecin 10476 423 couverture_medicale 10477 423 traitements 11137 423 departement 11138 423 ville 11139 423 notes_prise_en_charge 11304 423 notes_famille |
|
| RE: Compatibilité MySQL [ Répondre ] Par : Cyril Beaussier on 2015-02-20 11:41 | [forum:482645] |
|
MySQL gère les procédures stockées depuis la v.5 Donc ce n'est pas un problème. :-) Je n'ai pas vu le code source et si vous utilisiez une classe spécifique pour la connexion. Une solution serait d'utiliser une couche d'abstraction pour SGBD comme ADOdb ou AnyDB |
|
| RE: Compatibilité MySQL [ Répondre ] Par : Philippe MARTIN on 2015-02-20 10:01 | [forum:482644] |
|
Bonjour, Le code source du logiciel contient un grand nombre de procédures stockées PL/PgSQL, ce qui rend l'utilisation de PostgreSQL obligatoire. Cordialement Philippe |
|
| Compatibilité MySQL [ Répondre ] Par : Cyril Beaussier on 2015-02-19 16:41 | [forum:482643] |
|
Variation sera t-il compatible avec d'autres SGBD que PostGreSQL ? L'utilisation avec MySQL serait un plus. |
|
