Je partage le point de vue de HowTommy et j'en profite pour dire que je remets de plus en plus RESTful et REST HATEOAS en question. Mon problème est que cela cantonne nos µ-services à de simples et gros CRUD or - et pour paraphraser Chlouchloutte - si ton application n'est qu'un gros CRUD alors c'est que tu n'as pas de métier dedans, du coup quelle plus-value apporte-t-elle ?

Après, je sais bien qu'il est possible de se représenter l'intégralité de ce que l'on fait comme étant de la récupération ou envoi de données mais des fois, à l'image de la programmation impérative face à la programmation fonctionnelle, il est plus simple de demander à nos serveurs d'exécuter une action que de modéliser un traitement sous la forme d'une récupération de valeur.

My two cents

• L'indice des primary keys commence à 1 et non à 0 (donc faire bien attention avec des insert efrectués manuellement lorsque l'on veut s'assurer qu'un tuple dispose d'un ID en particulier).

• Mieux vaut utiliser des ID en UNSIGNED, par exemle :

  id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT

Ceux-ci permettent de n'avoir que des ID positifs et rangés pas ordre croissant, ce qui améliore la recherche. De plus votre limite passera de 2 millards d'entrées à 4 milliards d'entrées dans cette table.

• Préférez le type INT UNSIGNED à BIGINT (qui peut aussi être UNSIGNED). Vous ferai une économie mémoire d'environ 12% sur les recherches et économiserez 4 octets sur le disque par tuple ayant un id (et ceci pour chaque table).

Limitations :

• BIGINT UNSIGNED permet de gérer jusqu'à 2^64 - 1 entrées alors que INT UNSIGNED jusqu'à 2^32 - 1. On risque d'atteindre plus rapidement la limite non ?

==> Oui c'est vrai, mais admettons que :

• Notre système encaisse 100 000 insertions / jour.
• Cela fera 36 500 000 d'insertions / an.
• Soit 3 650 000 000 insertions pour 1 siècle.

Si votre application est toujours là dans 10 an ce sera déjà énorme alors 1 SIÈCLE !!!

Moralité, nous ne sommes pas Google.