--- In firebird-support@yahoogroups.com, David Johnson
<d_johnson@c...> wrote:

> Ultimately, many entities end up being very abstract nexuses (nexii?)

Okay, let's open up the first Latin lessons quiz.
I vote for 'Nexae' :-)

What else could be missing, especially about Firebird architecture as
far as I understand it: Along with a lot of normalization-processes
comes the splitting up of large tables into smaller ones.
Debtor-info could evolve from 1 completely unnormalized table easily
into 5 or 8 small tables linked by a key.

Updating the records will be much faster, especially in a network with
a lot of concurrent users. As far as I understand, Firebird keeps an
"old version" of a _RECORD_ , and not of a field, until the oldest
transaction needing this version is either committed or rolled back.

If you change only 1 field in a biiiiig table with a long running
transaction or even a "dead" transaction, then many more parts than
necessary of the database will be "blocked", and not marked for
garbage collection.

If you change the same field in one of many smaller tables and your
transaction goes to Nirvana, you still have a problem, but this
problem will be much smaller.

someone slap me, if I am telling nonsense here; am only working with
Firebird for 5-6 months.

ciao,
André