https://dev.mysql.com /doc/refman/5.7/en/create-table-generated-columns.html
Il est raisonnable que l'expression d'une colonne générée puisse référencer uniquement colonnes d'une même ligne. La colonne générée ne peut pas utiliser de sous-requêtes, ni référencer d'autres tables ou fonctions avec une sortie non déterministe.
Supposons que les colonnes générées prennent en charge les références de table croisée. Considérez en particulier le cas de STORED colonnes générées.
Si vous mettez à jour une table, MySQL devra également mettre à jour toutes les références dans les colonnes générées ailleurs dans la base de données, si elles référencent la ligne que vous avez mise à jour. Il serait complexe et coûteux pour MySQL de retrouver toutes ces références.
Pensez ensuite à ajouter des références indirectes via des fonctions stockées.
Considérez ensuite que votre mise à jour concerne une table InnoDB dans une transaction, mais que la colonne générée peut se trouver dans une table non transactionnelle (MyISAM, MEMORY, ARCHIVE, etc.). Votre mise à jour doit-elle être reflétée dans ces colonnes générées lorsque vous la faites ? Et si vous reveniez en arrière ? Votre mise à jour doit-elle être reflétée au moment où vous vous engagez ? Alors, comment MySQL devrait-il "mettre en file d'attente" les modifications à appliquer à ces tables ? Que se passe-t-il si plusieurs transactions valident des mises à jour qui affectent la référence de colonne générée ? Lequel devrait gagner, celui qui a appliqué le changement en dernier ou celui qui s'est engagé en dernier ?
Pour ces raisons, il n'est ni pratique ni efficace d'autoriser les colonnes générées à référencer autre chose que les colonnes de la même ligne dans la même table.
