Ton système de fichier n'efface pas complètement le dit fichier mais juste l'entrée du fichier ou pour être précis, quelques buts dans l'entrée pour dire "n'existe plus"
C'est pareil dans certains BDD, on marque les lignes à effacer, et on traite l'effacement par lot plus tard
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
J'aime bien cette approche aussi ça permet de faire des rollback facilement, c'est un truc pas si rare que ça je pense.
Godzil -> ça n'a quand même rien à voir, une entrée en BDD ne sera pas écrasée si elle existe encore, alors qu'un fichier effacé le sera sans autre forme de procès dès qu'il y aura besoin.
En plus c'est quand même pas la même chose, le côté historique et personnel d'un historique internet est bien plus évident que celui d'un simple fichier, et c'est bien là que le bât blesse.
Tout comme FB qui garde les données à des fins d'analyse, même une fois qu'elles sont marquées effacées.
Enfin bref, c'est encore une fois Apple donc forcément c'est génialement bien, c'est chiant ce parti-pris.
Uther Le 11/02/2017 à 08:27Edité par Uther le 11/02/2017 à 08:33 Sans être du tout un fan de Apple, je confirme que effacer des informations dans une base de donnée peut être une opération mois évidente qu'il ne le parait et que l'on choisis souvent de marquer comme désactivé à la place.
Le principal problème c'est que ça peut être compliqué a gérer et provoquer des bugs si d'autres informations de la base font référence à des informations supprimées. Il faut penser a gérer les impacts et les enchaînement de clés étrangères peuvent compliquer les choses.
Je parlais pas d'effacement, mais de traitement de données en base. J'ai du mal à croire que ce soit une opération aussi risquée sur des logiciels aussi éprouvés.
M'enfin, c'est sûr que je ne suis pas un spécialiste.
Pen^2 Le 11/02/2017 à 17:32 Mmmmouais.
Je suis loin d'être un expert bdd mais il me semble que les clefs étrangères, ça se gère, tout de même. OK c'est des dépendances, mais ça ne me semble pas insurmontable non plus.
Cela dit je veux bien comprendre l'argument que si le stockage ne coûte pas cher, c'est plus sûr de ne pas effacer. Mais ça reste une mauvaise solution pour le client à mon avis.
En l'occurrence les suppression peuvent etre fait par lot parce que c'est couteux de reorganiser la BDD pour toujours avoir de bonne perfs, d'où cette pratique courante de juste "marquer" les elements a supprimer, et 1x/jour (ou semaine) on fait le flush des element marqué a suppression et on fait une passe d'optimisation sur la BDD.
Perso ce truc ressemble plus a un bug/oublie qu'autre chose, autre point, Apple n'a pas accès au donnée qui sont stocké sur iCloud car... elle sont crypté, et seul tes appareils on les clefs pour accéder au données.
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Pen^2 Le 11/02/2017 à 22:10 (je ne sais plus exactement ce que l'article racontait mais ce n'était pas aussi clair concernant le cryptage apparemment)
L'article ne dit rien a ce sujet.
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
plutot "je ne'ai pas souvenir d'avoir lu un truc la dessus dans l'article en question"
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Folco le problème de la suppression c'est de garder le reste des données cohérentes.
il faut que l'intégrité de la structure de données soit maintenue même si tu interrompts brutalement l'écriture a n'importe quel moment. Sinon tu peux laisser le système dans un état intermédiaire "instable", et donc totalement inutilisable.
C'est loin d'être trivial a faire. Au taf c'est ce qui nous demande le plus de tests, parfois a la micro-seconde près.
là effectivement c'est plutot un problème de performance.
D'ailleurs si tu regarde les SGDB classiques quand tu fait un delete, les donnes ne sont pas reelement supprime, sinon quel interet de lui faire faire un GC de temps en temps?
On sais faire des suppressions "securise" avec peu de risque de corruption, mais c'est tres couteux en temps, et le faire des dizaines de fois par secondes est contreproductif. D'ou le faire explicitement ou non, de marquer les elements a la suppressionm et les traiter par lot
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Quelqu'un a pensé que ce serait bien de donner l'échelle, du coup
moyen glop, je vous dis.
Pen^2 Le 13/02/2017 à 16:34 Oué, mais un risque de 3 c'est élevé. Sachant que le risque 4 est apparemment le risque maxi, le 5ème niveau étant une interdiction totale. Enfin, quelque chose du genre.
vince Le 13/02/2017 à 16:47 je sais que c'est très très éloigné mais là j'ai la musique du jeu "ski or die" en tête
Mais en général, la boîte choisit ce qu'il y a de mieux pour elle (ou de moins risqué, en l'occurrence).
