Cor said:
Frank,
I am curious what is your goal with this.
The client is accessing a single thread of updating.
It can not read in that time inside one table because it does not know the
concurrency situation and with more tables it has to handle relations.
That's not true, depending on the locking mechanism you can select and
insert at the same time. In my database design, there are very little
concurrency issues. In other words, the clients access a different set
of data - never the same.
The connection is accessing over the network or over internet. However it is
one line, you cannot sinful optimize it by using more connections when it
would be to slow what is the normal reason for multithreading here. (Just
give more priority on that line when it is dealt with others)
Yes, you can, because the bandwidth needed for the commands to the
database is very low. The work is mostly done at either the client
level or the database level.
The database is accessing at full speed the given commands from the clients
one by one and needs as well concurrency synchronization. (However even
without that and with completly unrelated datatables can it only handle one
thing at time).
That's true and that's ok. I can optimize at the database level by
storing all indexes on a different drive, for instance. This way
physical I/O can work in parallel (sometimes). And, of course, you can
always throw more money at the machine.
I am really interested what you want to achieve and than how you would
handle your dependencies.
I am looking for robustness first, speed second. Mostly because you can
buy speed. You can't buy robustness.
