To, co widzisz, to problemy wynikające z kompilacji, a następnie dekompilacji kodu SQL.
human readable SQL -> compiled form -> human readable SQL
Nie martw się, to wszystko to równoważny kod. Jeśli potrzebujesz przykładu, napisz ręcznie JSON, przeprowadź go przez parser JSON, a następnie przekształć te dane z powrotem w JSON. Nie będzie wyglądać tak samo jak oryginał.
Jest to częsty problem podczas konwersji danych, znany jako „powrót w obie strony”. Bez dodatkowej pracy tracone są informacje niesemantyczne, takie jak komentarze, wcięcia i nawiasy (lub ich brak). MySQL może również stosować optymalizacje i przekształcenia semantyczne, takie jak zamiana FROM/GDZIE w JOIN. Tworzy również ukryty kod i wartości domyślne (takie jak ALGORITHM = UNDEFINED ) wyraźne.
Zobaczenie wyniku podróży w obie strony może pomóc w wykryciu subtelnych błędów w kodzie, zwłaszcza dotyczących kolejności operacji. Czasami dekompilator może zostać poproszony o dodanie dodatkowych nawiasów, aby kolejność była oczywista.
Nie ma sensu, aby MySQL przechowywał twoje oryginalne CREATE dla tabel i widoków, stają się one bezużyteczne, jeśli użyjemy ALTER. Możliwe jest jednak zwrócenie zapytań tak, jak zostały napisane oryginalnie.
