Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: Trucs & astuces [ Répondre ] Par : M Jung on 2015-09-10 13:44 | [forum:483429] |
|
XXX - ...... solution pour notre problème : pouvoir faire des requêtes sur des colonnes qui ne sont pas connues à la création de la base de données. - XXX Qu'est-ce que vous entendez par "colonnes pas connues" ? S'agit-il de vrais colonnes de BD ou de "pseudos-colonnes" ? Par ailleurs, et c'est un peu embêtant, il y a une erreur dans la BD : la table public.personne (per_id, ent_code) devrait être (per_id, ent_id)... |
|
| RE: Trucs & astuces [ Répondre ] Par : Philippe MARTIN on 2015-08-24 21:56 | [forum:483381] |
|
Bonsoir, Je rebondis sur votre remarque sur Ajax ... nous sommes justement en train de travailler sur l'ergonomie de l'interface web. À voir sur http://test1.variation.fr (c'est la plateforme de dév, attention, il peut y avoir des choses qui ne marchent pas entre 2 enregistrements ...) ou dans la branche bergame du dépôt git. N'hésitez pas à proposer des améliorations, les bonnes âmes et les conseils éclairés sont toujours bienvenus dans les LL. |
|
| RE: Trucs & astuces [ Répondre ] Par : Philippe MARTIN on 2015-08-24 20:47 | [forum:483380] |
|
Si si, j'ai bien compris que vous n'aimez pas ce modèle de données. Et je m'obstine à vous dire que ce n'est pas MON modèle. C'est le modèle EAV que je vous cite, que j'ai choisi, et que bien d'autres ont choisi pour faire des choses similaires : Magento, Drupal, et probablement bien d'autres. En exemple, regardez le schéma des données de Drupal : https://www.drupal.org/files/er_db_schema_drupal_7.png Je ne vois pas de table "page", et pourtant Drupal est un CMS ! Ce que j'attends de vous, car je suis toujours heureux d'apprendre de nouvelles choses et me remettre en question si nécessaire, c'est un début d'explication d'une solution pour notre problème : pouvoir faire des requêtes sur des colonnes qui ne sont pas connues à la création de la base de données. |
|
| RE: Trucs & astuces [ Répondre ] Par : M Jung on 2015-08-24 20:25 | [forum:483379] |
|
Bonjour, Mon post dans le forum n'était pas une question, mais si vous ne l'avez pas encore compris, l'expression de mon désarroi (pour ne pas dire plus) face à votre Modèle Conceptuel de Données. Quand j'ai appris à concevoir des Bases de données (à partir de 1985...PL/SQL était peut-être entrain de naître...) un pro d'Oracle nous a expliqué que si l'on ressentait le besoin de créer la moindre procédure pour interroger une base, c'est qu'il y a un problème de conception de base... Et depuis, je me tiens à cette règle (quand je conçois je me pose toujours cette question) et je n'ai jamais eu besoin de questionner une base programmatiquement pour en plus en assembler les bouts. Pour moi, le PL/SQL et autres, n'a d'ailleurs jamais été conçu pour ça, mais surtout pour exécuter séries de requêtes en fonction éventuellement du résultat de chacune (un peu à la manière des Job Control Language qui gère les batchs sur les mainframes) Ce qui est dommage, c'est que votre analyse fonctionnelle tient la route, - même si l'une ou l'autre fonction attendue n'est pas là et qu'il faudrait refaire votre interface conformément à ce qui se fait en Web moderne (vous utilisez mal AJAX, il faut "cliquer" pour rafraîchir ) et que vous avez une plateforme commerciale, une documentation etc... mais vous ne savez décidément pas concevoir une base de données correctement, ce qui m'étonne, car dans ACCUEIL rien ne m'a choqué. Je comprends très bien ce que vous avez voulu faire, mais il ne faut pas faire comme-ça, malgré votre obstination. Vous voulez faire une gestion des dossiers d'Usagers, et dans le MCD je ne trouve pas de table Usagers, qui pourtant devrait être l'Entité centrale du MCD !! A la place je trouve une table Personnes qui englobe aussi les Employés... Jusque là ça serait encore jouable, (limite) mais ça se gâte réellement quand vous "géométrisez" les données relatives à l'Usager et par conséquent aussi à l'Employé: l'Usager possède des propriétés qui lui sont propres et de même pour l'employé. Même si chacune de ces entités a des propriétés communes, il y a tout un tas que l'une possède et pas l'autre (par exemple l'usager n'a pas de salaire, l'employé oui, même si vous traitez pas cette question...), donc si vous confondez les deux en une seule entité, plus rien ne va. Quelqu'un a proposé l'utilisation d'une couche d'abstraction (Hibernate par exemple dans le monde Java, je ne connais pas les équivalents PHP), malheureusement votre modèle ne le permettrait pas, aucune chance que ça fonctionne et c'est bien dommage. Entre temps je viens de lire votre autre post: Dénormalisons les données : 1) l'unicité d'une donnée n'est pas le seul but du SGBD: il existe aussi quelque chose qui s'appelle "intégrité référentielle"... 2) des articles comme-ça on en lit tous les jours 3) et vous faites du SGBD R pas du BigData (où à ma connaissance l'intégrité n'existe pas et n'a d'ailleurs pas de sens) alors tenez vous aux règles du SGBD RELATIONNEL. En ce qui concerne le EAV (on en apprend tous les jours... et c'est certainement intéressant dans le bon contexte...la recherche médicale et autre), je viens de survoler l'article et je lis "EAV makes sense for categories of data, such as clinical findings, where attributes are numerous and sparse" en français: " la modélisation EAV a du sens pour les catégories de données, telles que les résultats cliniques, où les attributs sont nombreux et rares" : les attributs sont nombreux et rares ?? J'avoue avoir eu quelque difficulté à comprendre, mais finalement, c'est clair : les attributs peuvent être très nombreux dans une ligne de données, mais dans 99,99% des lignes ils ne sont pas utilisés (rareté), quelque chose comme-ça... en gros. Sommes nous dans ce cas ? Certainement pas, car quand on parle de beaucoup d'attributs, moi je pense à des centaines voire plus, ce qui est loin d'être le cas, surtout pas dans le domaine de l'informatique dite de Gestion... Et pour finir (ceci explique ma colère) si j'ai mis plus d'un mois à importer les données d'Accueil vers Variation (pas seulement les noms et prénoms des usagers, mais tout !! ), c'est qu'il y a un problème dont l'origine est à mettre au crédit de votre conception inadaptée au présent contexte. |
|
| RE: Trucs & astuces [ Répondre ] Par : Philippe MARTIN on 2015-08-24 18:50 | [forum:483378] |
|
Pour alimenter le débat, voici quelques éléments expliquant nos choix de conception de la base de données. Notre priorité a été de pouvoir définir depuis l'interface web un nombre quelconque de champs et inconnus a priori, et ceci à n'importe quel moment, même après la mise en place de l'application, et sans le soutien d'un informaticien. C'est pour cela que nous avons choisi un modèle du style EAV ( https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model ). À l'opposé du modèle que vous prônez, c'est un modèle qui favorise la souplesse de création d'attributs au détriment d'autres choses, j'en conviens tout à fait : - structure de la base de données : nous avons essayé de compenser ce problème en utilisant des procédures stockées, qui cachent la complexité de ce modèle, - performances : là encore, nous avons utilisé les procédures stockées pour que tous les calculs de requêtage se fassent dans le cœur du moteur de BD pgsql. Si vous regardez dans les logs de pgsql les temps de réponse pour la plupart des procédures, cela me semble tout à fait acceptable pour la plupart des procédures. Pour certaines procédures (de recherche notamment), nous envisageons d'introduire des tables dénormalisées remplies à partir des données de la structure EAV permettant des requêtes SQL comme vous avez l'habitude d'en écrire. Finalement, ce petit texte semble assez bien résumer la situation : http://www.cogoobi.com/blog/2009/01/26/caracteristique-de-la-bi-%E2%80%9Cdenormalisons-les-donnees%E2%80%9D/ . -- Philippe |
|
| RE: Trucs & astuces [ Répondre ] Par : Philippe MARTIN on 2015-08-24 17:27 | [forum:483377] |
|
Bonjour, La base a été conçue avec une surcouche de procédures stockées permettant d'accéder plus facilement aux données, documentées ici : http://api.variation.fr/html/ . Si vous regardez la quantité de code dans les procédures stockées, nous serons d'accord sur le fait qu'il y a pas mal de "petites astuces" à connaître sur la base de données : j'ai préféré cacher ces "astuces" dans les procédures stockées et fournir des procédures documentées qui cachent l'implémentation. Votre requête peut se réécrire plus simplement en : select concat('<', (select * from personne_info_varchar_get(927326099, 147, 'nom')), '><', (select * from personne_info_varchar_get(927326099, 147, 'prenom')), '><', (select * from personne_info_date_get(927326099, 147, 'date_naissance')) ); Il vous faudra récupérer un token, avec la fonction utilisateur_login2 ( http://api.variation.fr/html/re175.html ) -- Philippe |
|
| Trucs & astuces [ Répondre ] Par : M Jung on 2015-08-24 16:58 | [forum:483376] |
|
Il peut arriver que des utilisateurs, aient pour une raison ou une autre, besoin d'utiliser la base de donnée de variation à des fins statistiques, par exemple (...) ou encore pour en importer certaines données dans un tableur à des fins "calculatoires" ou dans un traitement de texte pour un publipostage, par exemple. Avec une base conçue en bonne et due forme, je crée généralement une requête SQL simple (moins de 2mn, montre en main) telle que : select nom, prenom, date_naissance from table_usagers where id_usager = 675; Généralement on a aussi besoin de quelques jointures, explicites ou implicites (selon les habitudes de chacun), mais cela ne représente toujours pas un écueil, même pour un non-informaticien, surtout s'il sait se servir des outils générateurs de requêtes et connecteurs SGBD fournis avec Microsoft Office ou OpenOffice, et autres Business Object, Pentaho, etc... Le degré de conception de la base variation est tel, que pour réaliser la même requête simple que citée précédemment j'ai besoin de "jouer" d'astuces et de beaucoup d'imagination... Trop d'imagination n'est jamais un mal, mais l'utilisation d'astuces est à proscrire en informatique tout comme dans toute autre discipline qui se respecte... Le besoin d'y recourir est généralement lié à une lacune de conception du système, quel qu'il soit... select concat('<',(select piv_valeur from personne_info_varchar where pin_id = (select pin_id from "public".personne_info where per_id = 675 and (inf_code = 'nom'))), '><', (select piv_valeur from personne_info_varchar where pin_id = (select pin_id from "public".personne_info where per_id = 675 and (inf_code = 'prenom'))), '><', (select pid_valeur from personne_info_date where pin_id = (select pin_id from "public".personne_info where per_id = 675 and (inf_code = 'date_naissance'))), '>') from "public".etablissement where eta_id = 1; qui me retournera, - enfin, une ligne contenant le résultat : <nom><prenom><datedenaissance> Le "from "public".etablissement where eta_id = 1;" est une astuce (il y en a peut-être d'autres ?) pour éviter que le corps de la requête ne renvoie qu'une seule ligne de résultat, ce qui est attendu. La concaténation du résultat des trois requêtes (une pour chaque donnée...) en est une autre, d'ailleurs largement utilisée dans les procédures contenues dans le SGBD de Variation.. Le logiciel Variation a en effet la prétention d'être hyper-adaptable à toutes les configurations organisationnelles du social, mais à quel prix !! Et je ne parle pas de l'impact sur les performances où l'on se situe très loin de l'optimum d'utilisation des ressources. Je suis persuadé qu'un SGBD conçu en adéquation avec les normes définies par MERISE (qui ne sont visiblement pas connues par les concepteurs de variation) doublé de techniques bien connues généralement utilisées pour l'internalisation des applicatifs auraient permis de créer quelque chose d'aussi prétendument génial, mais sans les limites liées de cette erreur conceptuelle. |
|
