LINUX.ORG.RU

SQL: как пропустить колонку INSERT INTO (col1, col2, dummy, col4)

 , ,


0

2

При добавлении данных в таблицу нужно пропустить колонку, которая в новой таблице больше не существует (перестала существовать, т.к. была удалена). Пример ниже не работает:

INSERT INTO tab(col1, col2, @dummy, col4) VALUES(1,2,3,4);

Нашел такое решение:

INSERT INTO tab(col1, col2, col4) 
SELECT 
  с1, с2, с4
FROM 
  (VALUES(1, 2, 3, 4)) AS x(с1, с2, с3, с4);

Может есть способ проще?
Можно ли подсунуть какую-то временную переменную?
(NULL и 0 не канает - я проверял)

P.S. Если добавлять по-старому:

INSERT INTO tab(col1, col2, col3, col4) VALUES(1,2,3,4);
то ругается:

MySQL error: (1054, «Unknown column 'col3' in 'field list'»)

Если указать существующую колонку дважды:

INSERT INTO tab(col1, col2, col4, col4) VALUES(1,2,3,4);
то ругается:

MySQL error: (1110, «Column 'col4' specified twice»)

★★★★★

Последнее исправление: Novator (всего исправлений: 2)

Что ты сделать-то пытаешься? Выглядит как несусветный бред. Почему ты не можешь просто вставлять три значения?

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Потому что дамп с данными уже существует, там 4 значения и вычленить третье тяжело.

Novator ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Да, кстати, решение работает только на MySQL2017 - на MySQL5.6 уже не работает.

Novator ★★★★★
() автор топика
Ответ на: комментарий от WitcherGeralt

Что ты сделать-то пытаешься? Выглядит как несусветный бред.

Пропустить 1 (одно) сраное значение - это элементарная вещь, которая должна быть в самой засратой БД.

Когда загружаем старый дамп, где на 1 колонку меньше - нет проблем.

А когда загружаем старый дамп, где на 1 колонку больше - всё, ад и погибель.

Кто так проектирует СУБД, что нельзя загрузить дамп в таблицу с удаленной колонкой?!

Novator ★★★★★
() автор топика
Последнее исправление: Novator (всего исправлений: 1)
Ответ на: комментарий от Novator

Создай временную таблицу, загони туда данные из дампа и потом из этой таблицы в нужную.

PS. Всегда знал, что MySQL - отстой.

FilosofeM ★★
()
Ответ на: комментарий от Novator

Зачем на лету? Создай заранее. Потом перельёшь через insert select.

WitcherGeralt ★★
()

Проблему решил так:
1) создаю таблицу с «лишней» колонкой
2) заливаю данные
3) удаляю колонку командой:

ALTER TABLE tab DROP COLUMN col3;

Шёл 2019 год...

Novator ★★★★★
() автор топика
Ответ на: комментарий от Novator

Это еще ничего. Вот когда есть вроде-бы ограничения (constraints), которые просто игнорируются базой - вот тут уже трэш.

FilosofeM ★★
()
Ответ на: комментарий от Novator

Т.е. вы в 2019 году считаете, что восстановить неполный дамп с дырами в данных - это что-то нормальное?

BaBL ★★★★★
()
Ответ на: комментарий от FilosofeM

Ну это при условии что вы их сами отрубили умышленно с помощью ignore constraints, но зачем тогда жаловаться на револьвер, когда сами стреляете себе в ногу?

BaBL ★★★★★
()

которая в новой таблице больше не существует

Ну так добавь временно, после вставки удалишь. Какие-то альтернативы предполагают правку дампа, а в таком случае можно просто удалить из дампа ненужные данные (регулярками, скриптом и т.п.).

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от BaBL

Речь идет о CHECK-ограничениях, а не PRIMARY/FOREIGN KEY. Поэтому в случае с Мускулем, револьвер стреляет сам по себе.

The CHECK clause is parsed but ignored by all storage engines

FilosofeM ★★
()
Последнее исправление: FilosofeM (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Так к 8-й версии на MySQL почти и не осталось никого. Все либо переползли на новую «народную БД», либо на на легаси 5.5, в лучшем случае 5.7, либо на Марие. В Марие, кстати, говорят проверки тоже только относительно недавно и работают они с оговорками.

WitcherGeralt ★★
()
Ответ на: комментарий от BaBL

Т.е. вы в 2019 году считаете, что восстановить неполный дамп с дырами в данных - это что-то нормальное?

Когда загружаем старый дамп, где на 1 колонку меньше - нет проблем.

А когда загружаем старый дамп, где на 1 колонку больше - всё, ад и погибель.

Кто так проектирует СУБД, что нельзя загрузить дамп в таблицу с удаленной колонкой?!

В чём проблема пропустить неиспользуемую колонку?

Novator ★★★★★
() автор топика
Ответ на: комментарий от Novator

Кто так проектирует СУБД, что нельзя загрузить дамп в таблицу с удаленной колонкой?!

Все?

Лучше покажи как бы ты решал подобную «задачу» с другими базами данных.

AnDoR ★★★★★
()
Ответ на: комментарий от Novator

Кто так проектирует СУБД, что нельзя загрузить дамп в таблицу с удаленной колонкой?!

Покажи мне хоть одну СУБД, которая так умеет. Если ты в запросе пихаешь 4 колонки, СУБД должна делать ровно то, что ты ей говоришь. И вообще дамп надо было после удаления делать

Harald ★★★★★
()
Ответ на: комментарий от WitcherGeralt

на MySQL почти и не осталось никого

либо на на легаси 5.5, в лучшем случае 5.7, либо на Марие

/0

Рассказы из разряда «пых никто не использует». Пол-веба, сидит на пыхе (с мускулом конечно), никуда не собирается валить, но это «легаси». Азаза.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Говоря такое про какую-то технологию я подразумею, что новые проекты на ней нормальные люди не пилят.

WitcherGeralt ★★
()
Ответ на: комментарий от no-such-file

Мне, кстати, MySQL привычна и по нраву, но я же разумный человек, с мейнстримом жизнь проще. Так что в новом проекте у меня postgres.

WitcherGeralt ★★
()

Читай про updatable VIEW

Stanson ★★★★★
()
Ответ на: комментарий от Novator

Кто так проектирует СУБД, что нельзя загрузить дамп в таблицу с удаленной колонкой?!

Все должны так проектировать.

В чём проблема пропустить неиспользуемую колонку?

Вдруг эта колонка твой ВИЧ статус? Задача дампа - восстановить целостные данные. Ты сейчас пытаешься доказать то, что дамп делает ПО ОПРЕДЕЛЕНИЮ - это неправильно.

Когда загружаем старый дамп, где на 1 колонку меньше - нет проблем.

Тут есть подмена понятий ещё, ты загружаешь не полный дамп со специально отключенными оговорочками. А полном дампе есть drop table if exists и лишней колонки после рестора не будет.

BaBL ★★★★★
()
Ответ на: комментарий от Novator

Кто так проектирует СУБД, что нельзя загрузить дамп в таблицу с удаленной колонкой?!

У тебя между версиями модель данных поменялась. Ты бы ещё дамп одного приложения грузил в схему другого приложения и удивлялся бы почему не работает. Либо бинарный дамп со схемой, либо дамп с миграциями. 2019 год, а люди дамп снимать не умеют.

Ну и кроме того, в правилах хорошего тона удаляемые колонки оставлять в схеме на заранее оговорённые срок.

anonymous
()

Чо за изврат? У тебя, как я понял, дамп из

insert into tab (a,b,c) values (1,2,3);
...
У тебя в новой базе нет колонки b и ты хочешь туда всё это запихать? Тебе не кажется, что ты пытаешься засунуть кубик в круглое отверстие? Или делай такую же схему или парси свой дамп.

crutch_master ★★★★★
()
Ответ на: комментарий от Novator

Когда загружаем старый дамп, где на 1 колонку меньше - нет проблем.
А когда загружаем старый дамп, где на 1 колонку больше - всё, ад и погибель.

Просто у тебя не дамп, а говно. Дамп из sql инструкций предназначен только для бекапа/восстановления такой же схемы. Хочешь плясок, делай дамп в какой-нибудь tsv/csv/json.

crutch_master ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.