>Sauf que dans ce cas il s'agit juste de faire une boucle incrémentant des indices d'après les voix.
Et donc il n'y a aucun risque d'avoir une corruption de données ? Avec un sgbd, tu as normalement des mécanismes sophistiqués pour éviter de n'écrire que la moitié de ton integer par exemple..
Bref, ça fait des années que des types bossent pour constuire un systeme robuste et sécurisé, alors qu'en fait il suffisait d'utiliser un fichier texte !
Pour les failles inutiles, il suffit de ne pas choisir un SGBD qui manque de maturité ( comme le SGBD, c'est un concept un peu plus vieux que le web 2.0, on en trouve quand meme quelques-uns ).
Et puis si on veut vraiment aller à l'economie de moyen et tout reinventer en se passant de l'experience accumulée depuis des décénies, on peut aussi de passer d'OS sur la machine et tout coder directement en ASM. Ca sera léger, rapide et surement blindé dès qu'on sortira du chemin nominal d'execution.
[^] # Re: .
Posté par snt . En réponse au journal Les machines a voter, définitivement pas sur.. Évalué à 2.
Et donc il n'y a aucun risque d'avoir une corruption de données ? Avec un sgbd, tu as normalement des mécanismes sophistiqués pour éviter de n'écrire que la moitié de ton integer par exemple..
Bref, ça fait des années que des types bossent pour constuire un systeme robuste et sécurisé, alors qu'en fait il suffisait d'utiliser un fichier texte !
Pour les failles inutiles, il suffit de ne pas choisir un SGBD qui manque de maturité ( comme le SGBD, c'est un concept un peu plus vieux que le web 2.0, on en trouve quand meme quelques-uns ).
Et puis si on veut vraiment aller à l'economie de moyen et tout reinventer en se passant de l'experience accumulée depuis des décénies, on peut aussi de passer d'OS sur la machine et tout coder directement en ASM. Ca sera léger, rapide et surement blindé dès qu'on sortira du chemin nominal d'execution.