Ali Gökçen wrote:

> 4+8+17+5*82+4+4+4+4 = 455 bytes, not so big.(confession: calc used)
> I hope your page size and disk block size match, like as at last 4KB.
> Also, exclude your fdb file type from antivirus programs, system
> restore services.

Hi Ali, I have not actively changed any default parameters - AFAIK
default page size _is_ 4 KB, isn't it? No antivirus is installed
either.

> Problem here is Foreign Key i think.
> It was a genetic promlem of FB and fixed in FB v2.
> if your referance column has thousands dulicates, don't use foreign
> key declaration. FB losts itself repeated index nodes with DISK I/O.
> Try to create your custom based integrity control system.

The foreign key column in the REQUESTS table points to the primary
index ID column in the USERS table. Of course, there can be only
one ID/USER with that value, but there might be thousands of
REQUESTS by that user. Does this rise the problem you mention?

BTW, I haven't noticed any timing problem in "normal" use. The
database just logs certain HTTP requests, and currently there
are just "some per second". When a HTTP request comes in, the
username and password are extracted, and the user is searched
in the database similarly to

SELECT ID FROM USERS WHERE UN=? AND PW=?;

(of course, there is an index on UN/PW)

Then, the request is executed, and the log entry is done by

INSERT INTO REQUESTS (..., USERID, ...) VALUES (..., <theAboveID>, ...)

So (if nobody deleted the user just during the millisecond of
the HTTP request process) it's generally impossible to insert
an orphaned REQUEST without the corresponding USER - and the
FOREIGN KEY wouldn't be necessary at all. I'm just using it
because of "good database design"... :-)

Best regards

Matthias