Blob and update
Установка Page buffers не помогла...
вот так это выглядит:
-------------------------------------------------------
вот так это выглядит:
Код: Выделить всё
CREATE TABLE OBJECTS (
ID INTEGER NOT NULL,
PARENT_ID INTEGER DEFAULT 0 NOT NULL,
TYPE_ID INTEGER DEFAULT 0 NOT NULL,
CH_COUNT INTEGER DEFAULT 0 NOT NULL,
OBJ_NAME VARCHAR(255) DEFAULT 'noname' NOT NULL,
STATUS SMALLINT DEFAULT 0 NOT NULL,
TYPE_DEVICE INTEGER DEFAULT 0 NOT NULL,
INFO BLOB SUB_TYPE 2 SEGMENT SIZE 16384
);
------------------------------------------------------------
ALTER TABLE OBJECTS ADD CONSTRAINT PK_OBJECTS PRIMARY KEY (ID);
------------------------------------------------------------
CREATE INDEX OBJECTS_IDX1 ON OBJECTS (PARENT_ID);
------------------------------------------------------------
CREATE PROCEDURE PROC_GEN_OBJECTS_ID
RETURNS (
ID INTEGER)
AS
BEGIN
ID=GEN_ID(GEN_OBJECTS_ID, 1);
SUSPEND;
END;
------------------------------------------------------------
CREATE TRIGGER INS_OBJ FOR OBJECTS
ACTIVE BEFORE INSERT POSITION 0
AS
begin
update objects ob set ob.ch_count=ob.ch_count+1
where ob.id=new.parent_id;
end;
------------------------------------------------------------
CREATE TRIGGER UPD_OBJ FOR OBJECTS
ACTIVE BEFORE UPDATE POSITION 0
AS
begin
update objects ob set ob.ch_count=ob.ch_count-1
where ob.id=old.parent_id;
update objects ob set ob.ch_count=ob.ch_count+1
where ob.id=new.parent_id;
end;
------------------------------------------------------------
...
type
TRecInfoReg=record
ID: Integer;
Info: TInfo;
end;
ArrayIDRegisters: Array of TRecInfoReg;
...
IBQuery1: TIBQuery;
Query2: TIBSQL;
...
IBQuery1.SQL.Clear;
IBQuery1.SQL.Add('select * from proc_get_object('+IntToStr(IDSubSt)+') where typeobj=23');
IBQuery1.Open;
Query2:=TIBSQL.Create(Self);
Query2.Database:=IBDatabase1;
Query2.Transaction:=IBTransaction2;
IBQuery1.FetchAll;
SetLength(ArrayIDRegisters,IBQuery1.RecordCount);
i:=0;
while not IBQuery1.Eof do
begin
ArrayIDRegisters[i].ID:=IBQuery1.FieldByName('IDObj').AsInteger;
ArrayIDRegisters[i].Info:=TInfo.Create(Self);
Stream:=TMemoryStream.Create;
(IBQuery1.FieldByName('blobinfo') as TBlobField).SaveToStream(Stream);
Stream.Seek(0, soFromBeginning);
Stream.ReadComponent(ArrayIDRegisters[i].Info);
Stream.Free;
Inc(i);
IBQuery1.Next
end;
IBQuery1.Close;
Query2.SQL.Clear;
Query2.SQL.Add('update Objects set info=:ParamInfo where ID=:IDObject');
for i:=0 to Length(ArrayIDRegisters)-1 do
begin
begin
if not IBTransaction2.Active then
IBTransaction2.StartTransaction;
Stream:=TMemoryStream.Create;
Stream.WriteComponent(ArrayIDRegisters[i].Info);
Stream.Seek(0, soFromBeginning);
Query2.ParamByName('ParamInfo').LoadFromStream(Stream);
Query2.ParamByName('IDObject').AsString:=IntToStr(ArrayIDRegisters[i].ID);
Query2.ExecQuery;
Stream.Free;
if IBTransaction2.Active then
IBTransaction2.Commit
end;
{здесь вызываецца практически такая же процедура, только она работает с объектами следующего уровня}
end;
...
Query2.Free
блин, ну ведь уже 10 лет говорят регулярно, что НЕЛЬЗЯ изменение каждой записи завершать коммитом при массовых вставках или обновлениях. Будет МЕДЛЕННО.if IBTransaction2.Active then
IBTransaction2.Commit
А за триггеры такие надо пороть... Что это за триггер UPD_OBJ, в котором торчит 2 update, БЕЗ проверки old <> new?
вот оно! даааа, с триггером я лоханулся конкретно.... матьбыевоперемать.... вот это спасибо так спасибо.... большое человеческое спасибоkdv писал(а):блин, ну ведь уже 10 лет говорят регулярно, что НЕЛЬЗЯ изменение каждой записи завершать коммитом при массовых вставках или обновлениях. Будет МЕДЛЕННО.if IBTransaction2.Active then
IBTransaction2.Commit
А за триггеры такие надо пороть... Что это за триггер UPD_OBJ, в котором торчит 2 update, БЕЗ проверки old <> new?
а про транзакции я уже говорил несколько раз - ничего не меняецца, как бы я их не коммитил...
Возвращай как было, на 0 =).CCB писал(а):Установка Page buffers не помогла...
Дмитрий, я же по поводу page buffers ничего не рекомендовал, только насчет page size. Надо же проверить разные варианты причин тормозов, сразу-то сложно определить, в чем проблема...kdv писал(а):и чем же он тебя настораживает? Может, у него в конфиге database_cache_pages другой стоит. Поосторожней с такими "рекоммендациями", пожалуйста.
Просто firebird скоростной, да и компы не 486-ые... . Но это не повод этим злоупотреблять.CCB писал(а):а про транзакции я уже говорил несколько раз - ничего не меняецца, как бы я их не коммитил...
P.S. CREATE INDEX OBJECTS_IDX1 ON OBJECTS (PARENT_ID);
Неверно с логической точки зрения. Вместо этого индекса должен быть foreign key на самого себя.
Таблицы ob нет - это альяс Objects. Смотри внимательней.WildSery писал(а):Не на самого себя, а на таблицу OB.
А про понятие "ссылочная целостность" слышал? Приведи конкретный пример, когда foreign key - не нужен.WildSery писал(а):Кроме того, foreign key не всегда нужен.
Ты называешь именем имя "OBJECTS_IDX1" ?WildSery писал(а):Может, человеку именованный индекс хочется.
Тьфу, точно.Таблицы ob нет - это альяс Objects. Смотри внимательней.
Да, это имя. И к нему можно обратиться. В отличие от "RDB$FOREIGNn", который может поменяться.Ты называешь именем имя "OBJECTS_IDX1"
Например, для упрощения репликации - не нужно тщательно следить за порядком вставки объектов.А про понятие "ссылочная целостность" слышал? Приведи конкретный пример, когда foreign key - не нужен.
А вообще, я в одной из баз не могу удалить ненужную больше таблицу из-за внешнего ключа. См. мой пост отдельный.
Бла бла бла. Начиная с FB 1.5, имена индексов внешних ключей по умолчанию "FK_ИМЯТАБЛИЦЫ_ПОЛЕВНЕШНЕГОКЛЮЧА". Собственно, в имени вся информация, которая нужна.WildSery писал(а):Да, это имя. И к нему можно обратиться. В отличие от "RDB$FOREIGNn", который может поменяться.
И это товарищи, знаете ли, правильно (С) Горбачев.WildSery писал(а):А вообще, я в одной из баз не могу удалить ненужную больше таблицу из-за внешнего ключа. См. мой пост отдельный.
(с сожалением) Э-э-х. Было бы неплохо.CyberMax писал(а):Бла бла бла. Начиная с FB 1.5, имена индексов внешних ключей по умолчанию "FK_ИМЯТАБЛИЦЫ_ПОЛЕВНЕШНЕГОКЛЮЧА". Собственно, в имени вся информация, которая нужна.
Жаль, что у меня не каталог журналов, на которые я подписан, а база средних размеров, но всё же 134 таблицы, 2165 процедур и 266 триггеров, которые сами некоторые как приличные процедуры по объёму. И таких баз 37 штук, почти одинаковых по метаданным, но разным по содержанию.
Я не возьму на себя ответственность "взять и переставить" на 1.5.
Проверено - работает - не трогай! (С) не помню.
Возвращаясь к проблеме с блобами - с задачей сохранения свойств компонентов я бы не парился, а закатал их все в ОДИН блоб.
Последний раз редактировалось WildSery 22 июн 2006, 15:44, всего редактировалось 1 раз.
Оффтоплю.
Если базы будут работать еще несколько лет, лучше все же перейти на 1.5, а потом и на двойку. Чем раньше, тем лучше. Лично у меня из крупных проблем при переходе на 1.5 была только одна - совпадение имен полей в запросах (ну коряво писал на sql). А вообще почитай про миграцию с 1.0 на 1.5 - там описаны все возможные проблемы. Может, не так сложно для тебя это окажется.WildSery писал(а):Я не возьму на себя ответственность "взять и переставить" на 1.5.