|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
20.01.2017, 21:12
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
FB 2.5, Delphi 7, компоненты доступа IBX Суть: - происходит импорт из внешнего файла нескольких десятков тысяч позиций товаров; - среди них есть много дубликатных (штрих-коды разные, а товар один), а записываться должны только новые товары, без дубликатов; - товары добавляются в таблицу БД запросом insert; - чтобы проверить на дубликатность очередной товар делается селективный запрос; Получается что каждый товар надо записывать в одной транзакции. Если записывать все товары в рамках одной транзакции проверочные запросы не работают (возвращают, что такого товара нет, т.к. транзакция записей не завершена). Но это намного дольше (раза в 3-5) чем если бы записывать все новые товары в рамках одной транзакции. Вопрос: есть ли какой-нибудь метод записи многочисленных строк в таблицу БД в рамках одной транзакции, но с возможностью проверять на дубликатность? И не в клиентской программе, где в этой ситуации, проверка практически невозможна. Или уж никак? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.01.2017, 21:14
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
авторВопрос: есть ли какой-нибудь метод записи многочисленных строк в таблицу БД в рамках одной транзакции, но с возможностью проверять на дубликатность? Читать из той же транзакции, через которую и записывать. Но вообще это тоже дурной тон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.01.2017, 21:18
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
А чем же этот способ дурён? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.01.2017, 21:27
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
SAN_01_08Получается что каждый товар надо записывать в одной транзакции. Если записывать все товары в рамках одной транзакции проверочные запросы не работают (возвращают, что такого товара нет, т.к. транзакция записей не завершена). ересь какая-то. если нет товара - значит нет его дубликата, значит insert. если есть товар, значит обновляем, update. никакой нужды все делать в одной транзакции при этом нет. кроме того, можно пользоваться конструкциями insert or update https://firebirdsql.org/refdocs/langrefupd25-update-or-insert.html или merge https://firebirdsql.org/refdocs/langrefupd21-merge.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.01.2017, 22:09
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
kdvесли нет товара - значит нет его дубликата, значит insert. если есть товар, значит обновляем, update. никакой нужды все делать в одной транзакции при этом нет. Не нужен здесь update - лишняя и бесполезная запись одних и тех же уже существующих в таблице данных. Нужда делать все в одной транзакции есть - скорость запись увеличивается в разы. Чего непонятного тут? И где в желании уменьшить время записи ересь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.01.2017, 22:30
|
|||
|---|---|---|---|
|
|||
Производительность запроса insert |
|||
|
#18+
SAN_01_08Чего непонятного тут? И где в желании уменьшить время записи ересь? Непонятно почему эту задачу возложили на тебя, наименее способного её выполнить. Чти http://www.ibase.ru/testiu/ до просветления. PS: Кстати, kdv, в этой статье разметка съехала, поправь. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.01.2017, 23:44
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
Dimitry Sibiryakov , что дают эти процедуры? Чтение текстового файла и запись или обновление данных? Ну не нужны обновления, если эти данные в таблице есть. Да и файлы из которых идет чтение информации это DBF. И непонятно как быть с транзакциями используя такие ХП. Да, конечно, я не гуру и далек от деталей и нюансов сервера FB, но именно поэтому сюда и обращаюсь за помощью. А просветления так и не наступило, хотя смысл ХП достаточно понятен. Но это не мой вариант. Вы, много знающие гуру, сказали бы просто: нельзя читать не подтвержденные завершением транзакций данные ни при каких обстоятельства, придумай что-нибудь другое. Или назвали бы корректные лазейки. Не мешало бы и вам вместе с Кузьменко просветиться и не опускаться до оскорблений и хамства. Взрослые, опытные люди, а не можете никак угомониться: все им, кто что не спросит, глупые и не далекие. Пора бы учится сдерживать свои барские замашки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2017, 00:01
|
|||
|---|---|---|---|
|
|||
Производительность запроса insert |
|||
|
#18+
SAN_01_08сказали бы просто: нельзя читать не подтвержденные завершением транзакций данные ни при каких обстоятельства, придумай что-нибудь другое. Читать можно. В той же транзакции. Но тебе - не нужно. Для твоей задачи хватит просто использовать insert и игнорировать ошибки нарушения первичного ключа. И не забудь, что в этом insert должны использоваться параметры. И препарироваться он должен один раз. А выполняться - много. В одной транзакции. В одной и той же транзакции. А в конце транзакцию надо закоммитить. Один раз. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2017, 00:07
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
SAN_01_08, Создай уникальный индекс (он и так должен быть) и просто вставляй по одной. Ошибки нарушения ключа игнорь. >Если записывать все товары в рамках одной транзакции проверочные запросы не работают (возвращают, что такого товара нет, т.к. транзакция записей не завершена). В это не верится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2017, 00:07
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
SAN_01_08Не нужен здесь update - лишняя и бесполезная запись одних и тех же уже существующих в таблице данных. Нужда делать все в одной транзакции есть - скорость запись увеличивается в разы. Чего непонятного тут? И где в желании уменьшить время записи ересь? 1. постановка задачи - ваши проблемы, я не знаю, нужен вам update или нет, мне пофиг. Просто предложил. 2. Ясен пень что вставки в одной транзакции быстрее, чем в отдельных. Именно поэтому все ваши попытки оправдать "невозможность" вставки в одной транзакции я и назвал ересью. Исходя из предоставленной вами информации с моей точки зрения никаких проблем не существует. Вы там что-то себе выдумываете, спрашиваете, вам отвечают, и не нравятся ответы? Дело хозяйское. SAN_01_08Не мешало бы и вам вместе с Кузьменко просветиться и не опускаться до оскорблений и хамства. Взрослые, опытные люди, а не можете никак угомониться: все им, кто что не спросит, глупые и не далекие. Пора бы учится сдерживать свои барские замашки. что???? вам бы перестать плеваться в отвечающих, если не нравятся ответы. Где я кого оскорбил, и хамил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2017, 11:46
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
Привет. SAN_01_08FB 2.5, Delphi 7, компоненты доступа IBX Вопрос: есть ли какой-нибудь метод записи многочисленных строк в таблицу БД в рамках одной транзакции, но с возможностью проверять на дубликатность? Я бы рассмотрел следующий сценарий: - в FireBird создается внешняя таблица формата исходного DBF; - из DBF создается файл в формате external table; - созданный файл подпихивается FireBird; - используя MERGE данные из внешней таблицы апдейтятся в целевую таблицу; Можно конечно использовать Код: plsql 1. Но на мой взгляд использование merge более гибко. С уважением, Polesov. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2017, 22:08
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
Polesov- в FireBird создается внешняя таблица формата исходного DBF; Firebird-у до лампы внешние форматы, включая dbf. external table - это один формат, который он понимает. Соответственно, вся идея от начала ущербная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
21.01.2017, 23:49
|
|||
|---|---|---|---|
|
|||
Производительность запроса insert |
|||
|
#18+
kdvPolesov- в FireBird создается внешняя таблица формата исходного DBF; Firebird-у до лампы внешние форматы, включая dbf. external table - это один формат, который он понимает. Соответственно, вся идея от начала ущербная. Он имел ввиду, dbf с откушеным заголовком - это external table со всеми полями char() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
22.01.2017, 00:16
|
|||
|---|---|---|---|
Производительность запроса insert |
|||
|
#18+
kdv, я имел ввиду внешнюю таблицу FB по формату полей совместимую с DBF. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.01.2017, 10:37
|
|||
|---|---|---|---|
|
|||
Производительность запроса insert |
|||
|
#18+
SAN_01_08, Если беспокоит производительность лишних селектов (хотя я не думаю, что это критично), закатай из DBF всё в GTT, а потом сделай merge (апдейтить не надо при этом). Я вообще сомневаюсь, что всё время надо импортировать несколько десятков тысяч записей. Если только в первый раз, потом всё меньше и меньше. Поэтому думаю селекты не критичны. Конечно, если есть индекс вменяемый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=40&mobile=1&tid=1561752]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
75ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 305ms |
| total: | 469ms |
| 0 / 0 |
