 Bonjour à tous, du coup, c'est pas que vous passez une bonne journée sur ce work on dirait, c'est très bon dîner, enfin, une minute, c'est bon. Donc on va pas poter de base de données, de represse, et on va essayer de comprendre le fonctionnement de la base de données. On va pas s'amuser à décortir les tables, on se fout. On va parler SQL conceptualisation, modélisation des données. Si ça pique, c'est pas grave, ça fait pas grave. L'idée, c'est d'aller creuser un peu les fondamentaux. Pour présenter l'adouement, je suis Thomas de Neulin, site CEO de WVP Arntella. Vous avez le nom là, là, partout. C'est une solution de mon adouement pour si vous avez une multitude de sites portables que vous voulez gérer dans un seul et même endroit. Et bien, en effet, pour ça. Et on a un petit standard. Donc c'est parti. Avant de rentrer dans le sujet, on va voir pourquoi c'est important de parler d'optimisation de base de données. Parce qu'il y a plein de coups d'optimisation. Que ce soit ça, c'est le fonctionnement le plus basique que vous avez si on doit parler d'un chargement d'une requête, quelle qu'elle soit quand vous arrivez sur votre site. Vous allez, je demande l'hompage. Pour récupérer l'hompage, il faut bien faire un requête en base de données pour récupérer les infos. En récupérant les infos, vous avez peut-être des traitements PHP, une baccaine, c'est peut-être autre chose que de lui poursuivre, et du fontaine qu'il affichera et vous utilisez le fontaine que vous voulez. Ça, c'est les différents couches si on s'implifie au maximum. Vous, l'optimisation, moi je dis vous, c'est pas spécifique pour quelqu'un, c'est moins compris. C'est que souvent, on va faire une petite couche en plus, on appelle le cache. C'est très bien. C'est pas un cache misère. C'est pour vous cacher les couches du tout. Donc, c'est pourquoi pas. On dit aussi que c'est super rapide à charger. Il est double méfait requête et de la balle. Oui. Il a plus de fer, mieux. Et on peut, une fois, ne pas mettre de cache et que ça se passe très bien. Et pourquoi la base de données ? Parce que si j'ai fait ce schéma dans ce sens-là, comprenez bien que si on optimise la couche la plus basse, naturellement, on n'écoute plus, soit on ne t'implie pas optimisé, mais on vous plie vite. Si votre base de données, par exemple, je sais pas, votre requête, en une seconde et que vous l'optimisez, ça prend plus que 500 ms. Sur tout votre processus, vous allez gagner 500 ms. Plus c'est bas, mieux, c'est plus c'est haut, plus ça, c'est rare. Maintenant qu'on a compris l'idée, l'optimisation, finalement, de la couche du plus bas niveau, on va faire un petit tour du plus bas. C'est bon ? C'est bon ? C'est bon ? C'est bon ? C'est bon ? C'est bon ? On va partir un peu dans les fondamentaux du esprit. Qui connaît les formes normales, les normales, les rapidement ? Vous êtes là ? C'est trop bon, merci. Comme ça, vous allez apprendre des trucs. C'est un peu l'objectif. Les formes normales, ça date pas d'hier, ça a été conceptualisé en 1970. J'étais même pas né. L'idée des formes normales, ça permet de faire la modélisation et la conceptualisation de vos modèles de données. Quand vous utilisez WordPress, vous n'y pensez même pas, parce que WordPress vous en bat, c'est à vous. Pour comprendre le fonctionnement de cette table-là, il faut savoir comment fonctionne la modélisation, sinon c'est pas possible. Les formes normales, vous vous imposez des contrats de modélisation et donc évitez la redondance des données, donc diminuez la volumétrie, parce que quand vous avez beaucoup de données, ça fait plus de temps. Empêchez les incohérences, parce que vous pouvez en avoir. Les incohérences, on verra plus tard, c'est très, très, très facile d'en faire avec WordPress. Et limitez les processus d'écriture bloquants. Parce qu'il faut bien vous dire que si votre modèle n'est pas normalisé, quand on parle de formes normales, je vais parler de FN, pas de politique, mais de formes normales, si c'est bien modélisé, vous empêchez les incohérences et c'est assez important. Il en existe neuf, honnêtement, j'en peux donner que les trois premières, parce que les six autres, on s'en fout un petit peu. Partout je suis passé, sans qu'on ne connaît pas, soit c'est tellement de granularité, pas trop d'effets. Généralement, on apprend toujours les trois FN, la première et la deuxième, la troisième formes normales. Et on s'arrête aussi à deux FN. Et encore une fois, c'est un concept, ça ne veut pas dire que c'est absolument ce qu'il faut faire, c'est comme tout, c'est pas un manifestant, nous-mêmes, sur l'embré, des fois, on a l'obligation de dénormaliser. Parce que c'est mieux, à un certain moment donné. Là, on va comprendre le concept, et ça nous donne de la matière pour réfléchir après. La première formes normales, on dirait FN pour aller plus vite, généralement. Donc, c'est une relation étant 1 FN, si toutes les colonnes contiennent des valeurs atomiques, un des visibles, que tous les enregistrements sont uniques, pour expliquer. C'est un concept que vous voyez, qui est la table étudiant, qui stocke le nom de l'étudiant, et c'est le cours auquel il participe. C'est un participe mal et physique. Le problème, c'est la première colonne. Les données sont pas atomiques. Vous ne pouvez pas faire ces informations d'un point de vue SQL, c'est absolument pas performant. Si vous voulez connaître le nombre de cours que fait Alice, bon courage. Il faut que vous récupérez la donnée, oui, mais je vais le faire empêcher, mais si tu le fais empêcher, tu es sur la peau du Dieu. Donc, tu parles en utilisations. Pour transformer cette modélisation, le FN nous dit, il faut que cette colonne soit atomique. On crée beaucoup de tables. On garde nos tables étudiants, il faut bien qu'on la garde, et on crée une table d'inscription d'un étudiant à un cours. L'étudiant 1, on le voit, donc il correspond à Alice. Elle est inscrite au cours de maths etc., etc. On est sur de la donnée atomique. Par contre, on a un problème. On a toujours plusieurs données. Donc, si demain, on vient de nous dire, oui, mais maths, il faut les créer avec un S ou il faut faire mathématique. Le processus bloquant, il faut mettre à jour toute la table. Et tous les endombroses à maths en place mathématique. C'est un peu... Vous avez des millions de données, ce n'est pas possible. Donc, il faut encore redégouper et tomber sur trois tables. Pour cette petite modélisation et toute modélisation, tout est dépendant d'un métier. Ce qui est un métier, c'est comptabilité. Le métier, le monde réel que je voulais représenter dans la grammatique. Et les métiers sont dépendants des besoins. Ce n'est pas parce que cette modélisation n'est pas assez normale, il faut dépendre du besoin. Deux FNs. De la deuxième forme normale. Pour passer à la deuxième, il faut être en première. Si vous êtes en première, vous ne pouvez pas être en deuxième. Toutes les colonnes non clés doivent dépendre entièrement de la clé primaire et non plus une partie de cesse. Là, on a une étape qui va gérer les notes des études. On va associer des étudiants de son cours. On va lui affecter sa note. Et là, on a aussi une colonne professeure. On va parler de métier. Professeur, on peut s'exploiter la question. Mais attends, c'est le professeur qui donne le cours ou le professeur qui donne la note. Ça dépend de votre métier. Donc là, dans un cas, la modélisation sera bonne, dans l'autre sera pas bonne. Moi, ce que je vais prendre comme cas, c'est le professeur qui dispose du cours. On met un peu de couleur. La clé primaire, c'est étudiant et cours. Il faut que l'on a besoin d'un étudiant et la cours pour donner une note. Professeur, il n'est pas dépendant de ces deux informations-là. Si c'est le professeur dispense du cours, il est dépendant de la clé cours et pas de la clé étudiant et cours. Et en plus, on a un problème, c'est qu'on a la redondance de données avec la note. C'est un petit phénomène. On a une table cours dans laquelle on a un cours, un mat. Là, je refais au final des exemples, le professeur qui dispense du cours qui est dans le cours. On est bon, on a un FN et un 2FN. On a une table étudiant, toujours elle-même. Et là, maintenant, une autre table de note, elle passe en 2FN. Un étudiant, étudiant 1 pour le cours, on a obtenu la note de 86. Détudiant 1 pour le cours, on a obtenu la note de 86. Bien, il y a 2FN. On avance. 3FN, 3FN2, ESP, dépense en 10 bits. Toutes les colonnes du table peuvent être directement liées à la clé principale et à une autre colonne qui est elle-même liée à la clé principale. La clé première, pour Aïdhi. On est sur une table cours. Le même table qu'on a vu il y a deux secondes au final. On a normalisé par contre. Maintenant, j'ai besoin de la née d'embauche de mon professeur. un professeur et dépendant de cour-à-aider, on l'a dit, jusque là tout va bien. Mais l'année d'embauche est dépendante, on a l'utilisation du professeur, elle n'a rien à voir avec le cours. Donc on est sur une dépendance sensitive, il faut encore caser quelque chose, il faut redécouper. Un cours, le cours mat numéro 1, on lui associe un professeur et on a une table, professeur, monsieur Loupompe, qui est l'année de la gauche, on en croit qu'elle est là. Ça va jusque là ? Ça c'est l'idée, je ne le montre pas pour le retenir, c'est pour vous, avec ça, je vais vous parler de choses concrètes sur le presse. Mais c'est que, qu'est-ce qui se passe dans votre presse et maintenant on ne va pas vraiment avoir envie de voir ce qui se passe. On va décortiquer un peu la base de données, le presse est tout stable, je vais pas vous faire l'établition à une ou, moi ce qui va m'interpeller, c'est celle-là, et je les associe parce qu'en fait, elle ne travaille pas l'une sans l'autre, ça a pas de sens généralement, et on va même aller juste sur une seule table, parce qu'on n'a pas non plus une heure, on n'a que très court temps pour faire beaucoup de choses, et vous donnez des deux épreins dans la train. On va s'intéresser sur WEP Post. C'est la structure, la modélisation de Post et PostMeta. Et il y aurait bien de choses à dire, mais vraiment un paquet. La première chose, c'est que par exemple, vous n'avez aucune clé étrangère. Clé étrangère en base de données relationnelle, ça vous permet de faire des contraintes d'intégrité, et les contraintes d'intégrité, si vous avez une base de données relationnelle et vous n'avez pas de contraintes d'intégrité, la faible d'une OSQL faible relationnelle, ça n'a pas de sens. Donc limite, il faudrait peut-être de l'esprit, vu la conception du truc. Donc ça veut dire quoi pas de contraintes d'intégrité, ça veut dire que là, si vous modifiez votre colonne post-auteur et que vous vous dites bah non, et que ce soit ceci à l'auteur numéro 1000, est-ce qu'il existe ? La base de données, il s'en fout, ça n'a pas. Donc vous avez d'un courgament de vos données. C'est la modélisation. C'est la même chose pour les PostMeta. Vous n'avez pas de clé étrangère sur PostEdit. Et puis après, on vient de dire, que les PostMeta, elles ne sont pas supprimées. Bah ouais, bah rajoutez une clé étrangère de PostEdit sur Post et mettez en cascade la suppression. Et là, d'un coup, les données vont disparaître toutes seules. Contraintes d'intégrité. On ne repasse le fait pas nativement parce que c'est l'avantage de sa conception. C'est la flexibilité, la compatibilité. Et c'est ce qui fait qu'on refraie ces coups pour beaucoup de choses. Compatibilité sur l'ancien système de gestion de la données, puisque je ne faut pas mal me rappeler que c'est un temps. C'est critiqueable, mais il faut comprendre pourquoi. C'est quand même un énorme avantage de cette flexibilité. On fait beaucoup de choses mais du coup, on le fait beaucoup. De n'importe quoi. Par contre, c'est tout moi. Alors, il n'y en a pas d'autre. Maintenant, si on va aller rigoler sur les inconvénients, il n'y a rien à faire. L'inconvénient de PostMeta, c'est que la colonne est à value. Pour rappel, PostMeta, PostMeta ID, PostID, un champ qui fait référence à PostID, mais ça faut le deviner. Parce que si vous utilisez un routine modélisation, il va vous mettre Post, PostMeta, personne ne sait qu'elles sont en relation. Personne, un pote ne peut pas le deviner. Il le devine parce que vous ne devez lui dire parce que vous n'avez aucune contrainte d'intégrer. Meta value est dépendante des développeurs et peut avoir des valeurs non atomiques. Donc, le problème, ce n'est pas tout à fait voir très si c'est le développeur. Donc, ça fait des noeuds 1FN. C'est-à-dire que si vous faites de caca d'avant, vous n'êtes même pas en 1FN. Dépendance partielle de la colonne meta value, donc, il faut revenir sur l'esprit d'avant pour appeler le 2FN, possibilité d'avoir des entrées multiples avec la même. Disons, mais PostMeta ID et Meta Ki, ça, c'est extraordinaire. Et performance dégradée, forcément, parce qu'il y en a partout. Ça, c'est pour vous montrer un tout petit exemple. C'est vraiment visuel. C'est tout ce que je suis en train de vous raconter. Et c'est la table PostMeta. Tout ce qui est là, vous pouvez la voir. Et ce n'est même pas vous pouvez. Je suis persuadé que vous l'avez dans vos bases. On n'a qu'un seul PostID et là, ce sont que des Meta Ki d'un seul PostID. Un seul, pas d'autre. Et elle est séparée. Premier problème. PostID, ce n'est pas une séparation étrangère. Ça, je viens de vous expliquer. Donc, ça veut dire que si je supprime le Post1, c'est une séparation de données. Elles ne sont pas supprimées. Si vous avez une séparation étrangère avec le délit en cascade, elles seront supprimées. La diminution de la volume étrangère. Deuxième problème. Non effets. Comment vous pouvez d'une idée ce qui se passe sur les ingrédients de ce post? Là, il y en a qui vont dire, oui, je ferai un like, faire un like, mon courage. Et on verra si c'est rapide. Donc, en fait, là, ce n'est pas possible. Vous ne pouvez pas le faire. Alors, attention, si vous dénormalisez, enfin, si vous normalisez, vous vous retrouvez avec sucre et parine, et vous pourriez faire un compte de cette table. Et pourquoi il faut aussi prendre des pincettes, c'est que le compte est les ingrédients en SQL. Ça fait qui? Donc, des fois, il faut dénormaliser et se dire que les ingrédients en SQL ont fait des données précalculées. Ce n'est pas normalisé, mais c'est pas grave. Parce qu'on sait ce qu'on fait. Troisième problème, dépendance partielle. La méta-value 30 est dépendant de la métallique hauteur H. Donc, elle est dépendant d'une colonne qui est dépendante elle-même de la clé publique. Il n'y a aucun problème. Aucune contrainte d'intégrité. Tu peux avoir deux postes métalliques dont la même clé, laquelle on prend au premier. Je ne sais pas. Cinquième problème, les données s'est réalisées. Les données s'est réalisées, c'est très gourmand. Et du coup, on ne pouvait juste pas les requêter. Ce qui prend de faire des requêtes sur des données s'est réalisées. Vous avez 89,9 % de chance que vous ayez des problèmes un jour. On va étudier nos requêtes en détail. On pourra aller plus loin et nous parlons de performance, mais ça serait cool de voir un peu des métriques. On va faire une requête avec 3 méta-données. C'est au title Keyword et une tombe lecture. Sur 25 000 postes et donc 75 000 valeurs en postes métalliques. Beaucoup. Ça, c'est la requête. Une requête. C'est la requête, elle est très sympa. Complait, volume de données, etc. Je vais l'exercer un peu parce que je vois qu'elle reste 10 minutes. Bref, personne en mille a l'air et moi non plus. Là, elle, elle est consommatrice et je vais garantir que ce soit un énorme jeu de données. Ça fait vraiment beaucoup. La requête, si vous faites des jeux d'essai pour 25 000 par résultat vous êtes à peu près à 330 000 secondes. Ça, c'est la représentation que ça devrait vous donner. Vous imaginez que je suis un élèver. Ma question, c'est est-ce que c'est rapide ? Moi, ma réponse c'est non. C'est très bel. Moi, mon conseil c'est créer vos tas. Un des conseils, il y en aura d'autres après. Les P-postes, c'est pour les articles. Il n'a pas assez été conçu. En tant que blog, il n'a jamais bougé. C'est pour les articles et uniquement les articles. Même avec ma table. J'ai conceptualisé notre table. Mieux normalisé, c'est pas top, mais c'est mieux. C'est juste qu'on vous restait sur la même typologie d'avoir de table. Là, il faudrait qu'une seule table. La différence, c'est que je n'ai pas une métacive qui fait n'importe quoi chez une colonne par typologie de métal. On va étudier la requête. Il y a un petit peu étrangère qui se cache qui est très très bien au bouton bas à droite. On va étudier la requête cette fois-ci sur 60 000 articles. Sur le matin, avec 4 méta. On en avait 3 avant. Ça, c'est la requête. Beaucoup plus simple. Et ça, c'est résultant. Pour 60 000 résultats, j'ai 147. Si on fait un petit comparatif, j'ai augmenté de 135 % de mes performances pour 2,4 fois plus de données. Et pour prémunir les questions, t'as fait exprès de prendre la meilleure ? Oui. En moyenne, on est souvent à plus de 50 % pour deux fois plus de données. C'est quand même beaucoup. Et on a optimisé la couche, la plus, passe. Donc, si on a vu tout ça, maintenant, je vais vous résumer l'épisode d'optimisation de ce qu'il peut être intéressant de faire. Etc. Première pièce, c'est déjà créer des index. Surtout pour votre table custom, parce que pour le reste des tables, on voit que ça fait le job depuis certains temps. Un index, c'est ce qui permet, c'est comme un dictionnaire. Si votre dictionnaire physique est un index, ça vous permet de réfléchir intelligemment comment chercher quelque chose très rapidement la complexité d'avoir un index. Alors, vous augmentez non, pardon, vous diminuez la vitesse de lecture, ça va très, très vite. Par contre, vous augmentez la complexité des créatures. Parce qu'à chaque fois, il va falloir qu'il place au bon endroit dans le dictionnaire. C'est toujours plus long, mais c'est agréable. Parce que les processus des créatures, même si je peux être bloquant, si vous êtes normalisé, vous avez un certain nombre de tables, j'ai un bras là, on en a 60 ans. Je suis en pleine, on en avait 170. On est chez WeGloves, on s'est promis. En fait, de nombre de tables, on s'en fout complètement. Plus vous en avez, mieux c'est quelque part. Parce que ce que c'est de la faute de nez, elle n'est pas rebondante. Elle n'est pas faite. Elle est plutôt bien faite. Et donc oui, et les clés étrangères nécessaires. Les clés étrangères vont vous créer de la contrainte d'intégrité, et ça vous permet d'avoir la cohérence d'engauder. De l'incohérence, c'est quoi ? C'est que vous pouvez avoir de mes taquilles avec deux fois title. Il y a un poste qui ne existe pas. La base de nez, elle vous dira, non, non, non, tu ne peux pas, le utilisateur n'existe pas. Je ne vais pas t'associer un poste à un utilisateur qui n'existe pas. Éviter les likes. Parce que ça, c'est très sympa les likes quand on voit en presse. Mais si vous mettez le pourcent en premier dans le like et que vous faites un like sur une colonne indexée, bah l'index, il fait, bah tu peux pas travailler sur l'index. En fait, vous avez un index pour optimiser la lecture et vous faites un like, il ne sert à rien puisqu'il ne peut pas l'utiliser. Donc, évitez quand même d'en faire. Même si ça peut être intéressant, ce n'est pas le truc à faire tout de suite. Évitez les or. Les or, ça fait des scans. Et plus vous avez d'or, plus vous augmentez le scan de données à faire. Allez, vas-y. On fait encore un bon paquet de performances. Évitez de se réaliser les données. Mais surtout, si vous devez la requetter, vous ne la sérialisez jamais. Si vous la sérialisez, il faut la tomiser pour qu'elle soit unique. Là, ça va, mais ça fure. Ça fure, ça fure, ça fure. Euh... Ce que vous devez apprendre à aimer et ce que beaucoup de gens n'aiment pas c'est un structurer vos données. Donc, apprenez à conceptualiser et à modéliser le métier sur lequel vous êtes en train de travailler. Évitez les thèmes avec leurs propres tables. Donc, vous commerc, ça s'y opresse, yos... Tout ce qui ont des custom tables, c'est parfait. Si vous commerc, ça fait des custom tables. Ce n'est pas pour plaisir, pas pour le plaisir des textes, pas pour un truc. C'est parce qu'au bout d'un moment, vous avez un million de données dans la table d'épée poste et qu'on dit non mais qu'elle charge en 10 secondes pour réaliser. C'est pour ça qu'on ne peut pas aller au propre table. C'est un peu fastidieux. Une fois qu'on le fait et qu'on fait un petit truc industriel, c'est cool. Mais en fait, ça va optimiser naturellement tout votre business. Qu'est-ce que vous devez maintenir? Et donc ça, c'est ce qu'on entend au global. Partout, ça ne change pas. Nettoyez les données en folie. Laissez par un étrange genre, qui ne sont pas expirés. Vous devez expirer les médias, enlever les médias qui ne servent plus. Vous devezoder la vision des postes. Ce qu'on le demande de révision par défaut des postes soit passés. Je vais pourvenir au poste d'avant. Il y a des temps avant 3, 2... Il n'y avait pas besoin de crainte. Désactiver les feedbacks et tradbac si vous n'avez pas besoin. Optimisez vos tables avec une petite requête qui s'appelle Optimize table et le monde d'autable. Souvent il va le dire. Je ne peux pas. Ah oui, c'est pas très bien conçu. des options dans les options qui sont autolodées. Ça apparaît, c'est bien avoir presse des pures donc souvent on part des feux de mémoire, je crois que quand les gens font des options, ça met yes, je crois que c'est la même part des faux. Et du coup, c'est autolode de donner. Et évidemment, si vous voulez optimiser aussi cette couche-là, faites moins de requêtes sur votre table d'options et arrêtez de charger des trucs à fond, mais ça malheureusement, c'est rarement de votre fait. Ça va être un peu clean ou un thème qui n'est pas bien son travail, mais ça ne vous empêche pas, à l'inverse, d'aller voir ça et dire, bah toi, je te mets un nom. Tu me fais la thume en charmant beaucoup. Voilà, on est arrivé au bout de nous, je suis dans les temps. J'ai vu 4 minutes de questions. Merci Thoreau, en fait, c'est bien dans le thème. Limite d'optimiser ta table. Exactement. D'accord. Alors, est-ce qu'il y a des questions, ou est-ce que c'était plutôt simple, que tout le monde a tout compris ? Limite de l'hyprince, ça sera l'apo juste après. En attendant, question... Ah, là-bas. Oh putain. Deux questions. C'est parti. T'es prêt ? Oui, c'est bon. Oui, je tourne la question dans la tête. Faire simple. Tu parlais au début de la fin de l'esprit, donc la poste métal, en effet, les métal agus ne sont pas... Il n'y a pas de contraintes. Quand tu parlais de faire, on va dire, limites, cascades, tout... Être sûr de nettoyer au fond de leur consuprime, ça n'est pas traité en natif, et tu conserres, mais concrètement, comment tu les imprimantes ? Je l'ai loupé quelque chose. Non, je n'ai pas du coup... En le temps, quand je n'ai des préférences en code, je n'ai pas d'installation privée. Ah non, c'est très simple. Est-ce que je comprends vraiment sur ce cas ? Oui, je comprends. Oh, suivez de journée. Ah non, attends, j'ai des vraies bases de données, parce que ça serait sympa. Hop. Donc ça, c'est adminaire, mais c'est comme THP Miami, nous, ce que vous voulez. Ce n'est pas mieux que ce soit, c'est juste que j'utilise lui, parce qu'il est natif dans le flag. Ne portez pas attention à ça. Ici, là, tu as ajouté une clé étrangère. Trois, vous cliquez, et vous dites, sursuprimez en dessous de cascades. Hop. Mais là, il faut qu'il soit à l'armes à nous, après avoir installé ton mot de presse, quand ta base de données est à la main. Tu peux créer une requête, est-ce qu'elle pourrait le faire ? Oui, bien sûr. Il faut presque clé étrangère. C'est content de l'intégrité. Et n'importe qui qui supprimera ta base dans le dili poste et que ça supprime, l'entrée poste, ça supprimera la possibilité. Non, après ça, je suis en milieu, notamment, avec des OVM sur des frais de l'arc PHP. C'est un truc clairement pas le cas qu'il pensait. Si tu veux de l'intégrité, c'est le mieux. Et l'espace ne le fait pas. Et il y a pas mal de choses qui tournent autour de la tolle d'une épée option qui est remplie de beaucoup trop de choses qui restent. Merci. De créer ses propres tables, du coup on peut utiliser l'admine de la represse facilement. Comment on s'en sort avec, par exemple, un custom post-hack procède, on le met plus dans le PHP poste, on met dans une table au PHP Recypes. Est-ce que tu as un plugin ? Tu n'es plus d'air. Ce que je vous raconte, c'est que la represse vous fournit zéro. L'avantage, c'est que ce n'est pas excessivement compliqué. Par rapport à l'admine, il faut faire autourfaire. C'est vrai que ce que tu dis d'isoler, c'est bien. Mais le travers, on te dit, c'est que tu détaches de la poudre d'attraction de la represse qui gère ça pour toi. Si tu peux utiliser les PHP query, tu peux directement penser pareil. Il n'y a pas de bonne solution. Non, c'est ça. En fait, je vous aborte les doutes et les trous. Je croyais avoir eu dans la plus d'entraîner un compte. Mais oui, il y a de la convenience, si la solution était si magique comme ça. En fait, après les boheurs, lorsque tu dis l'étable de commerce, je poursuis que ça devait évoluer a changé de chemin. Est-ce qu'il y a beaucoup trop... Justement, je pouvais un article, un article plus gros, qui te montre la différence avec un item, un order commerce, avec 25 métape, par rapport à une table de stone. Mais derrière, justement, c'était un article, maintenant il est un peu vieux, il a été déneveu, je crois, sur six semaines, avec six étapes de comment faire la propre table, et comment implémenter derrière toute la sécurité qui va avec... Parce que ça fut en raison d'un problème, alors si vous voulez une solution rapide et la plus efficiente, et finalement ce que le monde entier utilise, à part en presse, ça s'appelle des ORM. Donc rien ne nous empêche, en PHP, il existe Doctrine, qui est utilisé par Symfony et Outdoor. Vous prenez Doctrine, le proposer installe Doctrine, et vous avez un ORM, donc vos requêtes, c'est peut-être même pas de requêtes customes. C'est l'ORM. Si vous ne connaissez pas, vous cherchez Doctrine, vous l'installez, alors c'est pas un plugin, c'est du PHP, et en fait, vous vous importez votre ORM, enfin l'ORM, peut-être 30% de la communauté PHP utilise, et du coup, vous n'avez pas à faire 4 tables, vous n'avez pas à faire insert, into values, vers lui, machin truc, where, machin, l'ORM, c'est très, très simple, c'est de la programmation objet, vous faites du truc, et rien ne vous empêche d'utiliser un ORM, comme ça, vous installez, il est fait pour ce qu'il est fait, il y a pas un temps, mais pas aujourd'hui, et vous vous faites votre métier. Et l'ORM, vous êtes aussi rapide que n'importe quel autre techno, parce que ben, n'importe quel autre techno, il faut même qu'il crée aussi dans les mémons, et donc ça, c'était pour vous nous faire rapidement, ça, c'est non-entable pour lister nos backups, et on a plein de loge, nos compagnies, bah en fait, on se refait notre interface à 1000. Et les requêtes, on en fait 1 ou 2, elles sont optimisées, surtout ce qu'elles veulent. Bon, voilà, en plus en agence, l'avantage, c'est que l'idée, c'est qu'après, vous essayez d'industrialiser ce que vous faites de manière récurrente, vous faites une fois, mais comme ce que vous avez toujours fait dans toute votre vie, depuis que vous êtes en annonce, il faut bien faire une fois un moment donné, vous l'industrialisez, et puis vous améliorer. Donc vous y conseille si vous voulez faire, comme maintenant, votre doctrine, pour vos installs. Et c'est parti. Une autre question, Thomas. Merci pour ta présentation, tout à l'heure, sur la conférence, on remercie, enfin, on nous a fait un petit teasing sur pourquoi mais est-ce que elle était un mauvais choix de langage, est-ce que c'était un bon choix pour le represse ? Oui. Oui. Parfois, la réponse, moi, c'est que toutes les contraintes qu'on vient de voir. Vous avez su qu'elle était un très bon système de gestion de base de données relationnelle. Moi, j'utilise post-grade, d'un effet, les deux sont très grands. C'est... Moi, je n'aurai pas trop de déballage dessus. Surtout, t'as les SGVD relationnels, t'as les NoSQL, combo, etc. Tout ce que je peux vous dire, c'est que, à un moment donné, il y a toute une NoSQL, puis après, finalement, c'est assez malade. T'as des énormes industries comme bar, etc. Bon, le NoSQL, on n'a pas de... parce que c'est pas rapide, etc. Donc oui, pour la version NoSQL, c'est OK. Ne changez pas de SGVD. Gardez une NoSQL, c'est très bien. Si vous voulez faire post-grade, vous ne verrez aucune différence. Et après, les différences qui pourraient être existées vont être au niveau des extensions ou des choses comme ça. Et sur la volumétrie, je pense, la globale des sites que vous faites avec PITREST, même à un très gros e-commerce, pas de souci. NoSQL, il tient la charge, il faut. C'est... NoSQL ou post-grade. Et c'est un choix, c'est un peu comme ce sera ten-win. Faites votre choix. Soyez productifs avec, et c'est... c'est bien. Merci beaucoup Thomas. Applaudissements Je vous remercie d'avoir toutes les grandes informations sur les questions. Je vous remercie de voir plus à son stade qui est juste là.