1 - "Hey Bob, c'est quoi mon mot de passe déjà ?"
2 - "Au secours, je crois que quelqu'un a volé mon mot de passe et hacké notre système !"
3 - "On m'a donné un programme gratuit et quand je l'ai installé, mon système a crashé."
4 - "On va passer à l'outsource IT, tu pourrais former tes remplaçants ?"
5 - "Finalement, on a pas pris le programme que tu as testé"
6 - "Mon fils à besoin d'un job alors je le place au service IT"
7 - "Je suis d'accord pour qu'on passe à Windows 7, mais alors on n'achète aucun nouveau hardware."
8 - "L'AMF (Autorité des marchés financiers), veut tous nos e-mails des 5 dernières années "
9 - "Assurez-vous que personne ne gaspille du temps (donc de notre argent) sur Facebook !"
10 - "Coupe de budget sur le help desk, vous êtes dispo les week ends ?"
Autre (précisez svp)
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 ).
J'ai jamais dit qu'il n'y a aucun avantages à utiliser une BdD relationnelle !
Ben la présence d'un flag deleted par exemple.
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.
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
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...
La présence du flag "deleted" n'a rien d'illogique, au contraire.Envoyé par Ubiquité
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".
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 )
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).Envoyé par skeud
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.
Je suppose que tu es assez grand pour trouver un nom adéquat à tes données dans la base.Envoyé par Ubiquité
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").
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"
ç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...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager