Как правильно организовать частые добавления в БД

← →
Desdechado © (2005-10-04 10:36) [40]

> ПОСЫПАЛ ГОЛОВУ ПЕПЛОМ
Хорошо, хоть хватило мужества признать свою ошибку :)

> Тем более, что открытая транзакция напрягает сервер БД.
Тебе ее все равно открывать нужно, причем если на каждую запись своя транзакция, то открывать их нужно много, что больше напрягает сервер, чем 1 транзакция в секунду на 5-100 записей.

← →
ANB © (2005-10-04 10:46) [41]

> IBTransaction.StartTransaction;
> try
> for i := 0 to Buffer.Count - 1 do
> begin
> SetSQLParams(IBSQL, Buffer[i]);
> IBSQL.ExecQuery;
> end;
> finally
> IBTransaction.Commit;
> end;

- здесь никаких. Кроме лишнего кода. А лишний код - источник граблей. Плюс - а если кто то будет использовать эту процедуру и откроет транзакцию заранее ? Классические грабли в БДЕ : пишется процедура, которая запускает и коммитит транзакцию для одной записи. Другой программист пишет другую процедуру, в которой нужно добавить 2 связанные записи, одна из оторых очень хорошо добаляется первой процедурой. Не задумываясь, второй программист открывает транзакцию, добавляет свою запись, вызывает первую процедуру и наступает на грабли.

← →
Курдль © (2005-10-04 11:12) [42]

> IBTransaction.StartTransaction;
> try
> for i := 0 to Buffer.Count - 1 do
> begin
> SetSQLParams(IBSQL, Buffer[i]);
> IBSQL.ExecQuery;
> end;
> finally
> IBTransaction.Commit;
> end;

Странноватая конструкция...

Если уж на то пошло:

IBTransaction.StartTransaction; try for i := 0 to Buffer.Count - 1 do begin SetSQLParams(IBSQL, Buffer[i]); IBSQL.ExecQuery; end; IBTransaction.Commit; except IBTransaction.Rollback; end;

← →
sniknik © (2005-10-04 11:21) [43]

> Если уж на то пошло:

а так не лучше? во избежание ;о))
IBTransaction.StartTransaction; try for i := 0 to Buffer.Count - 1 do begin SetSQLParams(IBSQL, Buffer[i]); IBSQL.ExecQuery; if (i mod 1000 = 0) and (i <> 0) then begin IBTransaction.Commit; IBTransaction.StartTransaction; end; end; IBTransaction.Commit; except IBTransaction.Rollback; end;

← →
Val © (2005-10-04 11:25) [44]

>[36] Андрей Жук © (03.10.05 18:20)
что подразумевается? мне до сих пор никто не мешал написать:
create or replace myproc as lVar number; begin insert into my_tyable (my_field) values (1); commit; select max(my_field) into lVar from my_table; end; /

← →
Os © (2005-10-04 11:33) [45]

Грабли есть в постановке задачи.
- 1-я задача запись в базу
- 2-я задача чтение данных оператором.
- и появится 3-я задача, убирать ненужные данные после их обработки.
На запись данных потребуется свой компонент транзакции, чтобы его никто не зарулил в других задачах. Свойства транзакций надо задавать вручную, а не использовать по умолчанию.
И запись данных я бы организовал не по времени, а по заполнению буфера.

← →
Курдль © (2005-10-04 11:40) [46]

А почему никто всерьез не принял проблему "8 000 000 записей в сутки"?
Или все считают, что FB 1.5 нормально с этим справится?
Я думаю, что здесь нужен какой-то механизм архивирования утративших актуальность записей, или их полного уничтожения через определенный срок.

← →
Os © (2005-10-04 11:57) [47]

как я понял с постановки задачи это какой-то счетчик и записи за прошедший час нужно обработать и удалить.

← →
Sergey13 © (2005-10-04 11:57) [48]

2[46] Курдль © (04.10.05 11:40)
>А почему никто всерьез не принял проблему "8 000 000 записей в сутки"?
Потому что пока это только твои выдумки. 8-)
У автора нигде вроде нет требований работы 24*7. У него вообще видимо пропал интерес к этому своему вопросу. 8-(

← →
Курдль © (2005-10-04 12:21) [49]

> Ярослав (03.10.05 15:13) [14]
>
> Данные от устройства поступают непрерывно и целыми днями,
> и 5 - 20 записей в секунду это текущая нагрузка, она может
> увеличиться до сотни записей в секунду, вот я и думаю как
> это сделать, писать каждую запись отдельно... или какими
> нибудь пакетами
> Другие пользователи могут только читать эти записи, не добовлять
> не редактировать их не могут, да и пользователей немного
> 2-3 максимум 10
>

← →
Андрей Жук © (2005-10-04 12:23) [50]

>create or replace myproc
>as
> lVar number;
>begin
> insert into my_tyable (my_field) values (1);
> commit;
> select max(my_field) into lVar
> from my_table;
> end;

Оно то так, только если будет изменение множества записей в процедуре с commit в каждой итерации, то нарвемся на snapshot too old.
Вообще, Том Кайт в главе о транзакциях подробно описывает, почему нежелательна фиксация изменений в процедуре.

2[49] Курдль © (04.10.05 12:21)
Сори, действительно просмотрел. Но и тут непонятно, хранятся ли данные постоянно, или периодически "чистятся".

> Sergey13 © (04.10.05 11:57) [48]
> У автора нигде вроде нет требований работы 24*7. У него
> вообще видимо пропал интерес к этому своему вопросу. 8-(

Мы тут не только для того, чтобы авторов ублажать! :)
И даже не для того, чтобы "себя показать и на мир посмотреть". Зачастую полезно смоделировать и обсудить какую-то ситуацию, с которой, возможно, придется столкнуться самому.

>Андрей Жук © (04.10.05 12:23)
"если" можно придумать для чего угодно. если усердно искать проблем на задницу - обязательно найдутся :)
речь шла не о дурном применении коммита в процедуре, а о его невозможности, насколько я помню.

> Андрей Жук © (03.10.05 18:20) [36]
>
> > ЗЫ. А таки работа с транзакциями в оракле мне больше
> > всего нравится.
>
> Особенно невозможность сделать COMMIT в теле процедуры..
> .
- добавь прагму автономных транзакций и коммить сколько хочешь. А решение - верное.

Как правильно организовать частые добавления в БД Найти похожие ветки