Re: OO and relation "impedance mismatch"

"Louis" <louisducnguyen_at_gmail.com> wrote in message news:55756e6d.0410040745.1a2c4afa_at_posting.google.com...
> fredrik_bertilsson_at_passagen.se (Fredrik Bertilsson) wrote in message
news:<31f7e57d.0410020300.16f447fe_at_posting.google.com>...

> As a data boy I often see in Usenet, OO programmers ask why they
> shouldn't create tables and indexes and constraints on the fly
> (instantiate them as they would a class). The reason is that DBMS
> data lives on a physical disk(s). Even with RAM prices falling, I
> don't think it's feasible to store tens of millions of records in
> memory. As a data boy, I store all this data on physical disks and
> every night run maintenance jobs to apply/reapply indexes to make data
> retrieval reasonably fast. Furthermore, the inherent physical nature
> of a database lends itself to backups and restores.

I don't think so.

If you have 2 gigabytes of RAM, and you keep 80% of it for table storage, and your average row length is 160 bytes, there's room enough for 10 million rows in RAM, if I've done the math right.

What makes a database different from temporary storage is not RAM vs Disk, IMO. It's persistence and shareability. If persistent and shareable data gets irreparably lost or corrupted, or if its off the air when it's supposed to be on the air, the damage measured in dollars can pile up awfully fast. That's the real reason for backups.

It takes time to update an index, that's why it's sometimes done overnight rather than on the fly.

Likewise, it's the shareability of data that makes caution advisable when modifying its logical features on the fly. In essence, you may be breaking a contract with a potential user of the data. I mean "contract" in the IT sense, rather than the legal sense, although there's some overlap in the two. Received on Mon Oct 04 2004 - 19:35:10 CEST