-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/30/07 13:33, Brandon Aiken wrote:
> I always assumed the general argument is if you need to query different
> databases on the same server with the same application, they ought not
> to be separate databases because they're clearly related data.
Just because they are related, doesn't mean that it's always wise to
lump it all in the same database. Mainly for scalability and
performance reasons.
Our system looks like this set of databases:
REF database has all customer "low-volatility" data.
TRANS1 - Transaction data for accounts 0 - 999999.
TRANS2 - Transaction data for accounts 1000000 - 1999999.
TRANS3 - Transaction data for accounts 2000000 - 2999999.
etc.
This allows us to backup all the databases at the same time, and
horizontally scale as systems reach capacity
Currently, "joins" between REF & the TRANSx databases are handled by
the app server, but being able to attach to both databases and being
able to do distributed joins would really simplify our apps.
Of course, reducing the complexity of our apps means increasing the
complexity down to the RDBMS... And thus the balance of the
Universe is maintained.
> It's kinda like "why isn't there a way to do an exactly one to exactly
> one relationship between tables?". Well, because if one A always means
> one B and one B always means one A, shouldn't they ought to be in the
> same table already?
Vertical partitioning. If it's a large table, and certain columns
are "hot", while others not accessed so much, then partitioning the
table would speed up access to the hot column.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFv6G1S9HxQb37XmcRAumFAKCghFl/ryKtLQ+nlyP+jMRF3NJj1ACgruEU
wok9v3BkB6EFlJ01i/nYDLI=
=gzzP
-----END PGP SIGNATURE-----
