Discussion :

[Ubiquité]

Comme l'ont dit h2s84 et zeyr2mejetrem, le plus propre est d'ajouter un flag dans la bdd (méthode dite de suppression logique).

C'est très fréquent dans un logiciel de gestion qu'un objet de l'application soit lié à un utilisateur ou un client (je dirai même que c'est tout le temps).
Or, quand un employé quitte une société, il faut bien que son compte soit supprimé sans forcément que soient supprimées l'ensemble des données qui lui sont rattachées.

C'est pour ça que j'aime pas les bases de données relationnel, y a toujours plein de truc illogique.

[Invité]

C'est pour ça que j'aime pas les bases de données relationnel, y a toujours plein de truc illogique.

Un truc qui a été conçu en 1970 (je parie que t'étais pas encore né), qui a tout prouvé et qui continue de résister. S'il y avait plein de trucs illogiques je ne pense pas que ça resterait encore en vie.

[tchize_]

Comme l'ont dit h2s84 et zeyr2mejetrem, le plus propre est d'ajouter un flag dans la bdd (méthode dite de suppression logique).

Pas si la demande à pour origine la demande du client de supprimer toutes les informations le concernant (loi sur les libertés informatiques etc) mais que le devis est à conserver car toujours valable pendant les 3 prochain mois. Dans ce cas, une suppression logique, c'est tout simplement un refus d'appliquer la loi

La logique aurait voulu de simplement supprimé toutes les données du client à l'exception de son nom, ce qui, in fine, était la demande du patron (update table_client set ..... where id= ... )

[Lady]

Pas si la demande à pour origine la demande du client de supprimer toutes les informations le concernant (loi sur les libertés informatiques etc) mais que le devis est à conserver car toujours valable pendant les 3 prochain mois. Dans ce cas, une suppression logique, c'est tout simplement un refus d'appliquer la loi

La logique aurait voulu de simplement supprimé toutes les données du client à l'exception de son nom, ce qui, in fine, était la demande du patron (update table_client set ..... where id= ... )

Personnellement je le comprend comme ça aussi. D'où l'intérêt de se renseigner sur la raison de cette demande avant de choisir la solution à mettre en place .

[Ubiquité]

Un truc qui a été conçu en 1970 (je parie que t'étais pas encore né), qui a tout prouvé et qui continue de résister. S'il y avait plein de trucs illogiques je ne pense pas que ça resterait encore en vie.

Haha, un fanboy, un !
Si ca a traversé les ages c'est probablement pour raison de compatibilité ascendante.

[zeyr2mejetrem]

Pas si la demande à pour origine la demande du client de supprimer toutes les informations le concernant (loi sur les libertés informatiques etc) mais que le devis est à conserver car toujours valable pendant les 3 prochain mois. Dans ce cas, une suppression logique, c'est tout simplement un refus d'appliquer la loi

La logique aurait voulu de simplement supprimé toutes les données du client à l'exception de son nom, ce qui, in fine, était la demande du patron (update table_client set ..... where id= ... )

Le devis étant nominatif si tu demandes la suppression des informations te concernant via la CNIL (Loi du 6 juillet 78) ils doivent aussi être détruits.
Il n'en est pas de même pour les factures qui ont un droit de priorité sur ta demande car elles ont un délai de conservation fixé par une loi cadre (et par le principe qui dit que le FISC français a toujours raison ).

[zeyr2mejetrem]

Haha, un fanboy, un !
Si ca a traversé les ages c'est probablement pour raison de compatibilité ascendante.

Le relationnel n'est pas la panacée universelle mais nier ses avantages c'est soit être de mauvaise foi, soit ne pas connaître le sujet, soit avoir envie de troller un coup ... t'es dans quelle catégorie ?

[Ubiquité]

J'ai jamais dit qu'il n'y a aucun avantages à utiliser une BdD relationnelle !

[zeyr2mejetrem]

J'ai jamais dit qu'il n'y a aucun avantages à utiliser une BdD relationnelle !

Au temps pour moi, alors ;-)
Par contre je ne comprends toujours pas ce que tu vois d'illogique dans les bases relationnelles ...

[Ubiquité]

Ben la présence d'un flag deleted par exemple.

[zeyr2mejetrem]

Ben la présence d'un flag deleted par exemple.

Ben c'est utile et pas si illogique que çà.

Par exemple sous Windows t'as la corbeille où tu peux aller rechercher des éléments supprimés. Si tu peux aller les rechercher c'est qu'ils ne sont pas vraiment supprimés. Ces éléments sont justes flaggés.

[Ubiquité]

Ben c'est utile et pas si illogique que çà.

Par exemple sous Windows t'as la corbeille où tu peux aller rechercher des éléments supprimés. Si tu peux aller les rechercher c'est qu'ils ne sont pas vraiment supprimés. Ces éléments sont justes flaggés.

C'est pas vraiment la même utilisation. La corbeille c'est une suppression retardée, au cas où l'humain ne veuille finalement pas supprimer le fichier. Alors que le flag deleted c'est plutôt une fausse suppression, on veut supprimer une entrée mais on peut pas, alors on met un flag deleted à true, mouai.

[skeud]

Bizarrement, j'ai entendu cette phrase vraisemblablement plusieurs fois de la part de plusieurs développeurs.

Des mecs qui code un serveur en c++ qui va chercher des modules en dynamique avec des zoli heritage pour les modules?
Qui font des sites avec des template pour bien separer le traitement de l'affichage?

Perso je l'ai souvent entendu aussi c'est pour sa que je l'utilise tres rarement

Edit: oulah j'ai oublier de rafraichir, dis donc sa sollicite pas mal d'engoument tout sa ><
Effectivement j'aurais pu faire plein d'autres trucs mieux mais bon a 15h30, un vendredi faut pas trop en demander non plus
On verra lundi pour ameliorer tout sa

[Barsy]

Je suis en train de rajouter ça justement, mais le souci c'est que j'ai déja une case pour le personnel présent ou non, là c'est vraiment un cas spécifique qui ne s'applique que a LUI et à personne d'autre donc pas besoin de mettre une case juste pour lui, ça serait dommage

Enfin bon je fais des trucs bien t'en fait pas, j'ai juste poster ça pour montrer les trucs invraisemblable qu'on nous demande des fois

Je te prie de m'excuser, mon but n'était pas de te juger. Simplement, j'ai souvent récupéré des applications dans lesquelles mes prédécesseurs avaient "mis la poussière sous le tapis". Et résultat, ça fait des applications non-maintenables dans lesquelles la moindre évolution entraine des effets de bords.

Exemple rencontré récemment : Une demande d'évolution consiste à modifier le libellé d'un champ dans un formulaire. C'est le genre de truc qui se fait en 2 minutes. Ben non, car dans le code, le libellé du champ en question était utilisé comme clé pour récupérer une donnée...

Ben la présence d'un flag deleted par exemple.

La présence du flag "deleted" n'a rien d'illogique, au contraire.

Supposons que j'ai une application stockant les factures d'une entreprise. Pour chaque facture, je stocke les informations du commercial qui l'a émise. Si le commercial en question quitte l'entreprise, il ne faut pas que ses factures soient supprimées aussi. Et pour l'archivage, il faut qu'on puisse continuer à savoir qui est le commercial en question même s'il n'est plus là.

Enfin, s'il s'agit d'un client dont on souhaite réellement supprimer les données (pour raison juridique). Rien n'empêche non plus de vider les champs de la table pour le client en question, tout en laissant une entrée avec les clés primaires et étrangères. D'ailleurs, à la place de laisser les champs vides, il est peut-être plus intéressant d'y mettre un texte du genre "SUPPRIME".

[skeud]

D'ailleurs, à la place de laisser les champs vides, il est peut-être plus intéressant d'y mettre un texte du genre "SUPPRIME".

Je vois bien la tete du chef quand il regardera le devis:

Client: SUPPRIME.

crise de fou rire assurer

PS:T'inquiete pas, je connais sa aussi et j'ai pas pris sa pour une attaque, je justifiait mon "Je fais des choses bien". Mais comme j'ai deja vu dans le forum, qui n'a jamais coder un truc bien repoussant de temps en temps pour finir la semaine plus tot .

Un autre truc qui m'amuse bien c'est de voir un code bien degueu, le reprendre pour le rendre joli. Puis tu apprends que le stagiaire responsable de ce massacre revient, alors la je me fais un malin plaisir a creer un petit script qui va aller foutre le bordel dans le code en remplacant les nom par "var1,var2,var3" supprimer tout les espaces et retour a la ligne.Histoire qu'il comprenne un peu pourquoi il faut coder proprement (bien sur je fais une petite sauvegarde avant )

[Ubiquité]

La présence du flag "deleted" n'a rien d'illogique, au contraire.

Supposons que j'ai une application stockant les factures d'une entreprise. Pour chaque facture, je stocke les informations du commercial qui l'a émise. Si le commercial en question quitte l'entreprise, il ne faut pas que ses factures soient supprimées aussi. Et pour l'archivage, il faut qu'on puisse continuer à savoir qui est le commercial en question même s'il n'est plus là.

Dans ce cas là il faut mieux appeler le flag "employed" ou quelque chose comme ca.

[Barsy]

Je vois bien la tete du chef quand il regardera le devis:

Client: SUPPRIME.

crise de fou rire assurer

Normalement, ce n'est pas à nous de choisir quel texte doit s'afficher à la place d'un élément supprimé de la base. C'est justement le rôle du fameux "chef" (ou de la MOA si tu préfères).

De plus, ce n'est pas parce qu'une donnée est stockée d'une certaine manière dans la base qu'elle doit forcément être ressortie telle quelle à l'utilisateur. Dans un logiciel bien fait, il existe une couche métier entre l'accès au données et l'interface qui est censée gérer ça. Dans mon, cas, je proposais de remplacer les champs vides par une valeur pour simplifier l'administration de la base et non pas pour l'afficher.

Rien n'empêche d'afficher "ce client a été supprimé" si le flag est à true.

Dans ce cas là il faut mieux appeler le flag "employed" ou quelque chose comme ca.

Je suppose que tu es assez grand pour trouver un nom adéquat à tes données dans la base.
J'espère simplement que tu prends en compte les possibles évolutions de l'application. Rien ne garanti qu'on ne te demande pas plus tard de faire une distinction entre les utilisateurs "supprimés" et les "non-employés" (par exemple parce que certains utilisateurs sont des prestataires qui sont, par définition, "non-employés").

[souviron34]

J'espère simplement que tu prends en compte les possibles évolutions de l'application. Rien ne garanti qu'on ne te demande pas plus tard de faire une distinction entre les utilisateurs "supprimés" et les "non-employés" (par exemple parce que certains utilisateurs sont des prestataires qui sont, par définition, "non-employés").

Bah, il prend un alias "ubiquité", il est donc partout, en particulier dans le futur, le passé, et l'ensemble des possibilités

[tchize_]

Normalement, ce n'est pas à nous de choisir quel texte doit s'afficher à la place d'un élément supprimé de la base. C'est justement le rôle du fameux "chef" (ou de la MOA si tu préfères).

Ben si s'est le rôle à TOA, justement
Puis faut pas perdre de vue que, quand on peux modifier nous même les données, c'est là qu'on peux se faire plaisir. Imagine a la place de supprimé le devis qui ressort avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Client: Cible supprimée
Commentaire: A la demande de mr XXX, toutes traces nettoyées

Blague à part, on est bien conscient qu'on a toujours de traces qui restent même quand on respecte la CNIL (perso je m'en fous j'y suis pas soumis) ne serais-ce que par la présence même des backup, mais je pense que beaucoup perdent de vue que, dans une base de donnée relationnelle, quand on la construit, il faut absolument éviter de créer des contraintes non strictement nécessaires. Ce qui est naturel pour un programmeur ne l'est pas nécessairement pour la logique buisness qui est derrière. Sinon c'est vite la cata quand on tombe un "cas" inhabituel et on choppe alors ce genre de joyeuseté de type falg "supprimé","décédé", "a quitté l'entreprise". Tout ce qui utilise des jointure ne dois pas nécessairement avoir une contrainte de clé étrangère, les outer join ça existe

JE compte plus le nombre de fois où on a "exigé" que je fournisse certaines données dans des exports parce que la DB cible en avait absolument besoin, et que j'ai du prendre 1 à 2 h à expliquer au gars de l'autre coté que "non, je fournirais pas ces données car on ne les a pas pour tout le monde et, chez nous, ca pose pas de problème, qu'il se débrouillent avec ce qu'on leur envoie"

[souviron34]

Imagine a la place de supprimé le devis qui ressort avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Client: Cible supprimée
Commentaire: A la demande de mr XXX, toutes traces nettoyées

ça c'est A FAIRE de temps en temps, suivant les circonstances....

J'ai eu le cas, en météo : les méteorologues utilisent tout un tas de petits "trucs", élaborés par l'un ou l'autre après une vie d'expérimentation et de mesures... Pas des grands physiciens théoriques, juste des gars qui ont une idée , gardent et tracent les données pendant 30 ans, et après finissent par dire "bah.. On peut déduire un indice de si le vent va rabattre la fumée ou non lors d'un incendie en fonction de x ou y"..

Pour la météo, sur 38 indices comme ça, j'en avais 3 qui venaient de personnes qui n'avaient pas publié quoi que ce soit, mais dans le milieu ça se savait que c'était bon..

Donc j'ai codé les-dits indices, et dans l'explication (ou la bulle) correspondante, j'ai écrit "Pour plus de renseignements demandez à xxx no de tel ZZZ"".



Donc un tel commentaire n'est pas (forcément) aberrant...