Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.149.213.209] |
|
Данный раздел предназначается исключительно для обсуждения вопросов использования языка запросов SQL. Обсуждение общих вопросов, связанных с тематикой баз данных - обсуждаем в разделе "Базы данных: общие вопросы". Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Цитата Akina @ Оно, конечно, тоже вариант... но когда формальных ограничений (уникальных индексов) несколько, запрос начнёт пухнуть. Причём быстро - ведь ту же совокупность параметров придётся указывать литерально и в INSERT, и в каждом NOT EXISTS (или в каждом его WHERE). Ну и опять же - дополнительный, в общем ненужный, запрос. Да и обновление пойдёт фиг знает в каком порядке, поскольку все списки - и существующих записей, и добавляемых,- пересортируются для эффективного выполнения предыдущих этапов... Тут выбор невелик - либо проверять уникальные значения, либо получать ошибку. Я показал простейший вариант, причём не самый плохой. |
Сообщ.
#17
,
|
|
|
а речь о пакетной вставке тогда ИМХО лучше сначала сравнить нет ли в таргет-таблице дубликатов, а потом инсертить без задержек на проверку.
делаем SELECTs запоминаем ids тех что уже есть, далее инсертим того что еще нет, гениально не правда ли? |
Сообщ.
#18
,
|
|
|
Цитата Cfon @ а речь о пакетной вставке тогда ИМХО лучше сначала сравнить нет ли в таргет-таблице дубликатов, а потом инсертить без задержек на проверку. Тебе в любом случае придётся проверять каждую строку в пакете. И делать это именно в insert'e. Там можно сделать через join, но не уверен, что это что-то улучшит Добавлено Цитата Cfon @ делаем SELECTs запоминаем ids тех что уже есть, далее инсертим того что еще нет, гениально не правда ли? Ну да, скопировать пол-таблицы - это действительно гениальное решение |
Сообщ.
#19
,
|
|
|
Цитата Олег М @ Цитата Cfon @ делаем SELECTs запоминаем ids тех что уже есть, далее инсертим того что еще нет, гениально не правда ли? Ну да, скопировать пол-таблицы - это действительно гениальное решение нет я имел ввиду запомнить тока ids, но конечно стоит протестить. |
Сообщ.
#20
,
|
|
|
Цитата Олег М @ Тебе в любом случае придётся проверять каждую строку в пакете. И делать это именно в insert'e. Там можно сделать через join, но не уверен, что это что-то улучшит Я же указал два варианта решения. И оба - лучше, чем JOIN, как по ресам, так и по скорости. К тому же JOIN практически неприменим, если вставка идёт не из другой таблицы, а из списка (INSERT .. VALUES и т.п.). |
Сообщ.
#21
,
|
|
|
Цитата Cfon @ а речь о пакетной вставке тогда ИМХО лучше сначала сравнить нет ли в таргет-таблице дубликатов, а потом инсертить без задержек на проверку. делаем SELECTs запоминаем ids тех что уже есть, далее инсертим того что еще нет, гениально не правда ли? Зачем "изобретать велосипед" когда merge это уже делает без труда. |
Сообщ.
#22
,
|
|
|
Цитата Bas @ Зачем "изобретать велосипед" когда merge это уже делает без труда. как насчет пакетной вставки он нормуль? если да то пускай будет |
Сообщ.
#23
,
|
|
|
Цитата Bas @ Зачем "изобретать велосипед" когда merge это уже делает без труда. Ну если учесть, что у ТС имеет место быть MySQL, то MERGE слегка не в кассу. |
Сообщ.
#24
,
|
|
|
Спасибо за помощь и разъяснения.
|