Logique de fonctionnement

Salut,

Pas sûre que ce soit vraiment le bon endroit pour parler de çà mais bon.
Voilà je débarque dans une structure et je suis en charge de la reprise d'une application. Je parcours le code, trace les requêtes avec la base, fait du reverse avec JPA pour obtenir les graphes d'objet, etc...
Les clés des objets en base sont gérés par des séquences. Cependant je constate des trous. me dit que c'est certainement dû à des suppressions. Et en fait non car la suppression est seulement logique (passage d'un booléen à true au sens objet bien sûre).
En cresant je trouve la raison et c'est la que cela devient à mon sens tordu.
Lors de la création d'un objet tout est déroulé pour créer les enregistrements correspondant en base, cependant le check des contraintes fonctionnelles n'est fait que après l'insertion en base juste avant le commit. Si les contraintes fonctionnelles ne sont pas respectés (contrôlés par requêtage), alors on fait un roolback. cependant les numéros de séquence auront été augmentés entre temps. La personne en charge du développement jusque présent me certifie que c'est bien la meilleur manière de programmer....

Après cette présentation je pense complète voici les questions :
1. après quelques années de développements (java principalement) c'est la première fois que je vois un fonctionnement pareil. Pour moi il faut contrôler la cohérence fonctionnelle avant de faire les inserts dans la base, qu'en pensez-vous ?

2. Contrôler la cohérence fonctionnelle par requête n'est pas très logique pour moi, même si dans le cas présent on recherche dans la base si tel ou tel couple d'informations n'a pas déjà été créer, qu'en pensez-vous ?

Merci par avance de vos réponses,

Pas d'avis ?
ou bien j'ai tort à 100% ?

Bonjour,

Ah, on reconnait bien là les propos de cet informaticien modeste qui sommeille en chacun de nous : Si je le fais comme ça, c'est que c'est la meilleure façon de le faire !

Hors plaisanterie, je ne pense pas que tous les contrôles fonctionnels se font forcément de la même façon, et en plus ça dépend aussi du type d'application et du type d'architecture.

Citation:

---

Contrôler la cohérence fonctionnelle par requête n'est pas très logique pour moi, même si dans le cas présent on recherche dans la base si tel ou tel couple d'informations n'a pas déjà été créer, qu'en pensez-vous ?

---

En réponse à cette question, je dirais :

Premièrement :

Il y a de nombreux cas où la cohérence fonctionnelle nécessitent des requêtes en base de données, et on a parfois "double peine" à lancer les requêtes de contrôle, puis à faire les insertions/update nécessaires.
Parfois aussi, les accès concurrents entre divers utilisateurs font que le contrôle ne peut se faire que au moment de la transaction BDD .

Deuxièmement :

Si quelque chose risque de corrompre l'intégrité d'une base de donnée et que ceci est traduisible en contrainte d'intégrité de la BDD, alors il faut placer une contrainte d'intégrité

Troisièmement :

Tous ce qui peut être fait comme contrôle avant que l'utilisateur tape "enregistrer" devrait être fait, comme par exemple la cohérence d'un numéro de téléphone, un champs correspondant à une colonne non nulle, un format de date etc ...
Ceci n'empêche pas de mette en plus une contrainte par sécurité, mais c'est beaucoup plus performant et agréable pour l'utilisateur d'être prévenu avant d'une erreur prévisible.

Quatrièmement :

Si des contrôles sont faits à l'aide de contraintes dans la base, la façon dont ils remontent à l'utilisateur doit être très claire : pas du genre un immonde stack trace exception sur 30 ou 40 lignes de code java, ou peut-être pire "une erreur technique s'est produite : contacter l'administrateur !", mais quelque chose du genre :

Code:

---

"L'individu n'a pas d'adresse principale, créez d'abord une adresse"

---

Voilà quelques réflexions, par contre, malgré une expérience conséquente en conception de systèmes informatiques, je ne prétendrais pas que ces principes sont la seule façon de faire quelque chose de bien !


Cordialement

Je rajoute un truc au propos tout à fait corrects de semaphore1984:

toutes ces interrogation parce que vous avez des "trous" dans votre numérotation. En général, tout ce que garanti une séquence, c'est qu'elle ne fera que grandir, jamais qu'elle vous sortira tous les numéros de la séquence.

Par exemple, en oracle, par défaut, quand, dans une transaction j'ai besoin de 1 numéro sur une séquence, pour des raisons de performances, oracle m'en attribue directement 10 que les autres transactions ne pourront plus jamais utiliser. Si je ne les utilise pas tous, ben tant pis, ils sont perdus. Si j'ai besoin de plus, il m'en donnera plus par incrément de 10. Ainsi ma transaction (sans même savoir si elle réussira) recevra par exemple les numéros
2570, 2571, 2572, 2573, 2574, 2575, 2576, 2577, 2578, 2579, 2610, 2611, 2612

Ils sont croissant, et uniques, mais c'est la seul garantie que j'ai. Si je fais un rollback de la transaction, les numéros 2570 à 2579 et 2610 à 2619 sont perdus à jamais.

Si la contrainte fonctionnelle peut être faite en amont d'un insert et qu'elle invalide cet insert alors effectivement aucune raison de le faire :) et donc encore moins un très consommateur rollback.
Là c'est juste du bon sens AMHA.

PS: le choix de ne faire aucune suppression physique est par contre un très bon choix !

Je me rends compte que j'ai du mal m'exprimer.
Je ne pense pas avoir "LA" solution, c'est juste que je trouvais cette approche déroutante étant donné que je ne l'avais jamais vu. Ce qui m'a surtout surpris c'est que le responsable des dév m'a assuré que c'était l'unique manière de procédé en programmation, et que en gros si je faisais pas comme çà j'étais un naze.

Qu'entendez-vous par :
<< on a parfois "double peine" à lancer les requêtes de contrôle, puis à faire les insertions/update nécessaires.>> s'agit-il des temps de réponse ?
J'ai fait un test. j'ai gardé la même logique de contrôle par requête mais je l'exécute avant les insert plutôt que après. je gagne près de 3 secondes de traitements. mais malgré cela le responsable trouve cela illogique car il s'accroche à son approche (d'où mon questionnement).

Pour les deuxièmement, troisièmement et quatrièmement, je suis on ne plus d'accord avec toi.

En ce qui concerne les trous dans la numérotation je suis aussi d'accord en fait cela devient un "problème" car cette clé est devenu fonctionnel, ce qui pour moi est une abération. j'essaie d'expliquer au fonctionnel que cette clé est technique et que si elle doit suivre un ordre établi il faudra faire des modifications dans l'application. mais cela est difficile à comprendre semble-t-il.

La fuite est parfois salutaire !

RE-bonjour,

Rassures toi, la petite pique que j'ai lancée, qui est à prendre au second degré, ne t'était pas destinée, elle est plutôt pour ton responsable de dev, et ce que tu dis ensuite, ne fait que renforcer ce sentiment, mas c'est humain somme toute.

Par double peine, j'entends que parfois, lorsqu'on veut contrôler certaines règles, on est obligé, soit au lancement de l'IHM (page web ou écran d'application) de lancer des requêtes qui ramènent des infos pour permettre les contrôles, ce qui dans certains cas peut être couteux et donc ralentir l'affichage de la page ou de l'écran avant ou pendant la saisie. Mais il est souvent malheureusement nécessaire de récupérer ces mêmes infos au moment de la transaction car les infos ont pu changer suite à l'action d'autres utilisateur ou que la mécanique utilisée n'a pas la mémoire de ce qui a été fait (un EJB stateless par exemple).

Il y a d'autres cas que je n'ai pas en tête, mais ce qui est sûr c'est qu'il est difficile de trouver une solution universelle !

Pour ce qui est de la séquence, tout à fait en phase avec tchize_ et toi-même pour ne pas mélanger les id techniques avec des numéros fonctionnels.

Si vraiment il faut un numéro fonctionnels unique, on peut aussi utiliser une séquence, mais il faudrait que ce soit sur une autre colonne que l'ID et qu'il ne soit renseigné que si la transaction est comitée, voire après coup par un système de validation par batch, tout dépend du contexte !


Cordialement

Je comprends tout à fait que certains cas puisse nécessité une récupération d'information de dernière minute. Pour ce qui est d'incrémenter ce champ j'avais pensé comme toi à un batch.

Plus généralement, cette discussion contribue largement à me rassurer.
Mon côté j'ai pas trop confiance en moi m'oblige toujours à remettre en cause mes pratiques et mes connaissances, ce qui est salutaire pour mon évolution professionnel mais fatiguant pour mon mental. Cependant je suis toujours autant surpris qu'en j'entends parler d'une nouvelle approche et qu'on me martèle que c'est la bonne pratique.