Pour la première question, tu parles de quelle table en particulier ?
Parce que c’est pas normal, j’ai du oublié un “unique” quelques part !
En fait j’ai mis des uuids dans certaines tables quand ce sont des données qui sont communes à tous les utilisateurs/ ou qui a un moment seront utilisés entre plusieurs instances gladys.
Exemple 1 : table sentence
La table “sentence” regroupe une liste de phrases qui sont utilisées pour entrainer le réseau de neurone qui va classifier les questions de l’utilisateur. ( “Allume la lumière”, etc… ). Ces phrases sont sur un repo github et l’objectif est de mettre régulièrement à jour cette base de phrases afin de pouvoir améliorer Gladys au fil du temps sans forcément mettre à jour le software complet.
Imaginons du coup qu’une phrase avait une erreur ( du genre j’avais mal orthographié le service appelé ), et que je veuille mettre à jour sur toutes les gladys cette phrase, il me faut pouvoir identifier avec un id unique cette phrase. Or l’attribut “id” dans la table est propre à la db du user, et peut être différente dans chaque base ( car le user peut rajouter des phrases à lui potentiellement ). La seule solution est d’avoir un “uuid” unique qui permette d’identifier et de mettre à jour cette phrase 
Exemple 2 : table House
- Pour la table House & Machine, la raison est différente. Imaginons que tu ai plusieurs instances de Gladys, une dans une maison et une autre dans ta maison de vacances. Imagine que tu veuille mettre en place un bus MQTT central où sont publié des events (genre “allume lumière 1” ). Les deux instances sont connectés au bus, cependant elles ne doivent attraper que les events liés à leur maison/machine, et du coup il faut une façon de pouvoir identifier de façon unique chaque maison/machine, et comme dans l’exemple précédent l’id n’est pas suffisant car juste unique dans la DB d’une machine.
Le nom de la maison pourrait être l’élément différentiateur, mais bon je préfère générer un UUID qui identifiera de façon unique la maison.
C’est vrai que j’aurais pu du coup virer l’id simple qui est inutile dans ces tables, après d’après ce que j’ai lu les perfs sur les JOIN sont bien moins bonne quand la clé primaire est un UUID… Mieux vaut garder l’id integer en local à mon avis
edit: Je suis allé jeter un coup d’oeil, visiblement la table House et Machine n’avait effectivement pas la contrainte “unique”, j’ai corrigé ça 