PEBKAC #8224

Toujours pour la même application dont je lisais l'aide l'autre jour.
Pour des tests, je dois faire correspondre notre base de données en lieu et place de la base SQLite intégrée. Problème technique : ce qui semblait être des identifiants générés aléatoirement dans la colonne id se trouve être en réalité un simple hash d'une ou plusieurs autres colonnes pour chacune des tables.

Je peux comprendre leur idée de faire appel un hash pour faciliter les appels à la base à la récupération d'un identifiant à partir d'une autre colonne censée être unique… Néanmoins, pas pour outrepasser ces appels et se baser sur le hash seul qui risque de provoquer des collisions.
Par ailleurs, leur base ne gère aucune contrainte de clé primaire ou étrangère, ni même d'index. Mais elle ne se prive pas de faire appel à des jointures… Est-ce là une particularité au développement avec SQLite ?

Autant la dernière fois l'erreur d'interprétation était de ma part, autant là… PEBKAC.

PEBKAC #8224 proposé par mAn le 27/07/2013 | 8 commentaires | 👍🏽 👎🏽 +78

Ce n'est pas très reluisant de votre part de vous moquer de cet élève de 3e. Je comprends tout à fait qu'il n'ait pas su mieux gérer le projet de son pifenmoins patron.

Commentaire #103774 écrit par H. Finch le 27/07/2013 à 08h39 | 👍🏽 👎🏽

Hé zut, moi qui comptais la faire, la blague sur mon pifenmoins patron ! Mais bon, je ne pouvais pas : je n'ai rien pigé au souci, perso...

Commentaire #103776 écrit par Aaargh!!! le 27/07/2013 à 08h42 | 👍🏽 👎🏽

C'est parce-qu'il est atteint de SQLite aïgue!

sors en courant

Commentaire #103807 écrit par Pyrhan le 27/07/2013 à 10h52 | 👍🏽 👎🏽

C Partiellement TLP pour penser que la collision des hash est un problème dans ce scénario. C'est une pratique courante, git par exemple utilise sans complexe SHA1 comme identifiant unique de ses objets et sans aucun mécanisme de protection en cas de collision.

Si le système utilise sqlite j'imagine qu'il n'est pas redondant, la probabilité d'une corruption du support de stockage est largement supérieure a celle d'une collision.

Par contre pour l'absence de clefs primaires, en effet, ça s'excuse pas.

Commentaire #103819 écrit par b0fh le 27/07/2013 à 12h16 | 👍🏽 👎🏽

CTLP pour avoir écrit un PEBKAC commençant par "toujours" (pensant qu'on avait lu le précédent).

Commentaire #104026 écrit par Blaaaah le 29/07/2013 à 01h40 | 👍🏽 👎🏽

J'avoue que je ne suis peut-être qu'un débutant mais à ce que je sais un identifiant doit être nécessairement unique, ce qu'un hash ne garantit pas aussi grand soit-il.

Dans le cas de cette application, il se trouve dans le domaine [1, 2^53] ce qui est j'avoue... phénoménal ! Mais ce n'est pas parce qu'il est immensément grand qu'il prévient de collisions. Le rôle d'un hash est de faciliter la recherche de données en l'indexant, pas d'identifier.

Ainsi, même s'il couvre un grand intervalle, celui-ci se doit de rester beaucoup plus petit que le domaine indexé, sans trop l'être toutefois pour éviter d'avoir trop de collisions (ce qui ne les interdit donc pas).

Après, concernant l'absence de clefs primaires et je pense aussi un peu de cette histoire de hash, les auteurs ont choisi de purger de la base des données vieilles de plus de 15 jours pour éviter les ralentissements car elle se rempli vraiment très vite ! Et même avec cette purge j'ai pu voir les performances de machine rapidement s'amoindrir...