MySQL: способ каскадного выбора параметров типа столбца для всех таблиц?

Question

Я реорганизую нашу базу данных MySQL, меняю таблицы MyISAM на InnoDB и задаю внешние ключи, и мне интересно, есть ли способ также связать настройки столбца?

Пример:

в моей таблице useraccount пользовательский столбец varchar (20). Во всех моих других таблицах другой пользовательский столбец для записи, кто ввел запись, также varchar (20).

Мне интересно, как можно связать все эти зависимые пользовательские столбцы, например, если бы мне пришлось изменить столбец useraccount.user на varchar (40), могу ли я установить для всех остальных пользовательских столбцов таблицы каскадный на varchar (40)? ) а?

Я уверен, что мог бы использовать информационную схему для написания PHP-скрипта, но я бы предпочел, чтобы база данных модифицировала себя без посторонней помощи, если это возможно. Можно ли это сделать с помощью триггера в записи схемы для столбца username.user? И если так, могу ли я тогда также создать триггер для автоматического добавления ограничений внешнего ключа для любой новой таблицы, в которую добавляется столбец «пользователь»?

кажется, что это должно быть возможно, но я признаю, что недостаточно хорошо знаю MySQL, чтобы разбираться с таблицами схем;)

Редактировать: Вот пример SQL, который я написал, чтобы найти несоответствующие таблицы

SELECT TABLE_NAME, COLUMN_TYPE
FROM information_schema.COLUMNS 
WHERE TABLE_NAME != 'user_accounts'
AND COLUMN_NAME = 'user'
AND COLUMN_TYPE != (
    SELECT COLUMN_TYPE 
    FROM information_schema.COLUMNS 
    WHERE TABLE_NAME = 'user_accounts' 
    AND COLUMN_NAME = 'user'
)

В идеале я хотел бы использовать этот результат information_schema для циклического прохождения каждой строки вышеуказанного результата и изменения таблиц ALTER для изменения типов столбцов в соответствии с типом столбца user_account.user

Answer 1

В SQL DDL не работает каскадно.

В стандартном SQL вы бы использовали домены (которые, к сожалению, MySQL не поддерживает).Допустим, у вас этот код PostgreSQL хранится в вашей системе контроля версий.

create domain USER_DOMAIN varchar(15) not null;

create table users (
  user USER_DOMAIN primary key
);

create table another_table (
  user USER_DOMAIN references users (user),
  other_column char(1) not null,
  primary key (user, other_column)
);

Когда возникает необходимость, вы можете изменить одну строку кода в управлении версиями.,.

create domain USER_DOMAIN varchar(20) not null;

.,,сбросьте данные, загрузите новую схему, перезагрузите данные, и все готово.Но имейте в виду, что это может занять много времени в огромной базе данных.(Перемещение данных занимает больше всего времени.)

Вы можете выполнить то же самое в MySQL, даже если он не поддерживает оператор CREATE DOMAIN.Вместо SQL используйте макропроцессор m4 .

# test.m4 -- demonstrate replacing CREATE DOMAIN with m4 macro.
define(`USER_DOMAIN', `varchar(15) not null')dnl

create table users (
  user USER_DOMAIN primary key
);

create table another_table (
  user USER_DOMAIN references users (user),
  other_column char(1) not null,
  primary key (user, other_column)
);

Затем выполните этот код через m4 как часть вашего make-файла.m4 заменит USER_DOMAIN на 'varchar (15) not null').

$ m4 test.m4

create table users (
  user varchar(15) not null primary key
);

create table another_table (
  user varchar(15) not null references users (user),
  other_column char(1) not null,
  primary key (user, other_column)
);

Теперь переход на varchar (20) по-прежнему выполняется только в одну строку.