Hi Matthias,

> 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.
>

correct, you can also check it with ibexperts personal editon-
pulldown menu/services/database properties.

for HD info:
chkdsk C: command in realmode-DOS-box via start-run, CMD or command.

> > 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?
>

there is no problem with users table but requests.
foreign key on user(id) declaration doesn't effect user table.
it check only if there is a unique key on id of user table.
if ok, than it creates a duplicate index on request tables user_id
column.

> 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)

There is no risk here.

>
> Then, the request is executed, and the log entry is done by
>
> INSERT INTO REQUESTS (..., USERID, ...) VALUES (...,

<theAboveID>, ...)

>

Yup, there must be too much index values with same USERID value.
It is very heavy duty for FB, to maintenence of index table.
insert, delete, update operations will be very slow.
you can check this by inactivating FK. Firebird will start to fly,
instead of turtle animation.
you may be cannot sense this time difference by only one
insert-delete-update operation, but under bulk operations or
multiuser load you will notice it easly.

> 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
>

You are right, referential integrity must be at system level and it
is a must for a good database design. We should to accuse borland
because they didn't fix this critical problem for long years.
We are triying to racing a hand brake enabled ferrari in F1.
Regards,

Ali