https://dev.mysql.com /doc/refman/5.7/en/create-table-generated-columns.html
Rozsądne jest, że wyrażenie dla wygenerowanej kolumny może odnosić się tylko kolumny w tym samym wierszu. Wygenerowana kolumna nie może używać podzapytań ani odwoływać się do innych tabel lub funkcji z niedeterministycznymi danymi wyjściowymi.
Załóżmy, że wygenerowane kolumny obsługują odwołania między tabelami. W szczególności rozważ przypadek STORED wygenerowane kolumny.
Jeśli zaktualizujesz tabelę, MySQL będzie musiał również zaktualizować wszelkie odwołania w wygenerowanych kolumnach w innym miejscu bazy danych, jeśli odwołują się do zaktualizowanego wiersza. Wyśledzenie wszystkich tych odniesień byłoby dla MySQL skomplikowane i kosztowne.
Następnie rozważ dodanie odwołań pośrednich za pomocą funkcji przechowywanych.
Następnie należy wziąć pod uwagę, że aktualizacja dotyczy tabeli InnoDB w transakcji, ale wygenerowana kolumna może znajdować się w tabeli nietransakcyjnej (MyISAM, MEMORY, ARCHIVE itp.). Czy Twoja aktualizacja powinna zostać odzwierciedlona w tych wygenerowanych kolumnach po jej dokonaniu? Co się stanie, jeśli się wycofasz? Czy Twoja aktualizacja powinna zostać odzwierciedlona w momencie zatwierdzenia? W takim razie w jaki sposób zmiany MySQL powinny „kolejkować” zmiany, aby zastosować je do tych tabel? Co się stanie, jeśli wiele transakcji zatwierdzi aktualizacje, które mają wpływ na wygenerowane odwołanie do kolumny? Który powinien wygrać, ten, który wprowadził zmianę jako ostatni, czy ten, który wprowadził zmianę jako ostatni?
Z tych powodów zezwalanie wygenerowanym kolumnom na odwoływanie się do czegokolwiek innego niż kolumny tego samego wiersza w tej samej tabeli nie jest praktyczne ani wydajne.
