Как (и можно ли) добавить в таблицу поля с вычисляемыми именами на голом MySQL?

Question

[Александр Батухтин]

Да не просто с вычисляемыми, а на основе данных из других таблиц.
Есть таблица languages:

id	name
1	Русский
2	English

И есть таблица, скажем, countries:

id	gid
1	russia
2	france

Нужно в таблицу countries добавить ещё два поля для хранения названий на соответствующих языках:

id	gid	name_1	name_2
1	russia
2	france

Это реально на чистом MySQL?

Comments

[sheknitrtch]

В англоязычной литературе это называется «pivot table» и связано с OLAP-кубами.
Попробуйте поискать на stackoverflow.com по словам «mysql» и «pivot».

[Александр Батухтин]

Они же, вроде, только для выборки используются, или я что-то не так понимаю? Как это поможет изменить структуру существующей таблицы?

[Павел Волынцев]

Не очень понятно, что конкретно должно быть в колонках name_1 name_2

[Александр Батухтин]

В будущем — названия стран на языках из первой таблицы.

Answer 1

[Alexander]

copist: Не очень понятно, что конкретно должно быть в колонках name_1 name_2

0lorin: В будущем — названия стран на языках из первой таблицы.

То есть при появлении новой записи в languages, в таблице countries добавить поле равное `name_` + languages.id?
Отвечу, что нельзя голым майскулом. :-)
Потому что автосоздание вы можете по вешать по сути только на тригер. А он не дружит со склейкой имён полей из переменных(CONCAT). Сам с этим воевал. Пробовал даже создать функцию, которая бы обращалась к полю, имя которого должно собираться из составных частей. Но триггеры послали меня в лес, сказав что «хитрый какой, мы видим что ты в функции создаёшь поле из переменных».
Ни создать, ни даже обратиться к такому полю.
Если же создание поля будет у вас выполнять php, а не MySQL, то там вариант niko83 вам подойдёт.

Но я бы всё таки сделал как советует boodda. С годами пришёл именно к такому варианту. Особенно когда начал использовать ОРМ джанги. Просто на HL проекте не стоит всё завязывать на MySQL. Многие вещи, особенно если это списки. Порой проще вытаскивать из БД и перебирать уже кодом. Ну и для обработки больших списков помогают такие вещи как MongoDB или noSQL

Comments

[Александр Батухтин]

Спасибо, добрый человек. Вопрос закрыт, буду шаманить с php.
Поменять что-либо сейчас не в силах, потому что эта система уже давно живёт.

[Alexander]

Да не за что. Сам просто когда-то убил не один час решая подобную задачу.
У меня при создании пользователя, в зависимости от типа учётки, которую выбрал пользователь при регистрации. Должна была идти автоматом запись в отдельную БД. Где были свои поля вида name_1, name_2, name_3, name_4(цифра тип учётки). В будущем значение в поле изменялось по своей логике.
Вот тогда и решил, что не хочу делать этого на пхп, сделаю ка я всё средствами майскула. Благо триггеры на события вешать можно(создание, удаление, изменение // до события или после события). А там как не воевал, так не удалось ничего предпринять со сбором полей из составных частей. Потому что триггеры это не позволяли. И обмануть триггер через засовывания логики в функцию, а триггером вызывать её передав параметр. Хотя если просто делать запрос, вне триггера, то выполнялся он нормально. И функция без триггера тоже нормально работала.

Answer 2

[niko83]

Попробуйте подход как тут forums.mysql.com
(пример из страницы по ссылке)

set @addcoltext = concat('ALTER TABLE nick.mytable ADD COLUMN ',concat('day',dayofmonth(curdate() - interval 1 day)),' INTEGER UNSIGNED;');
prepare addcol from @addcoltext;
execute addcol;
deallocate prepare addcol; 

Answer 3

[ivnik]

Может получится решить проблему с помощью view?

Comments

[Александр Батухтин]

Не очень понимаю, как.

Answer 4

[boodda]

А вам это действительно надо?
Возможно вы подошли в решению задачи не с того боку?
Я к тому что, возможно, вам проще сделать третью таблицу, в которой хранить

country.id | language.id | name

?

Comments

[Александр Батухтин]

Нее, лишние запросы, лишние джойны… медленно это всё.
Да и в любом случае от меня уже не особо зависит. Есть продукт, он стоит у кучи клиентов, им надо накатить апдейт, который включает в себя такое вот изменение структуры таблицы.
Придётся, видимо, через php подлазить…

[boodda]

ну как это медленно, что тут особо медленного то?
Джойны так же кешируются, здесь они будут простыми, а новые колонки тоже кто то обрабатывать должен, такое же изменение логики, причем не совсем очевидное, а если языков будет 100, что 100 полей добавить?

[Александр Батухтин]

Наверное вы правы, но тут не я решаю.