I have to say this first -- just because ERwin calls it "physical" that doesn't mean anything. ERwin uses "physical" model to mean "product-specific logical" model. They use "logical" to mean "product-independent logical" model.

ERwin doesn't do physical modeling. Not even a little bit. The physical layer of a relational database …

Time is simple. You can make it complicated with any one of a large number of dumb-as-dirt decisions.

In the Real World™, time may be a quantum field (read stuff by 't Hooft ). For that matter, space itself may have some quantum granularity. Or, this could be a handy hack …

The money quote was this "It’s not a big leap then for me to consolidate all three of those into one uber relationship table...".

The question was a good one because it involved the classic higher-order database relationship.

The canonical SQL relationships are binary equi-join relationships that can be …

In order to talk about what goes in the database, we need to put the question into some kind of useful context. Weirdly, the question came to me in a context so twisted and bizarre that it's a little hard to sort out what -- precisely -- was going on. First, what …

Physical Tuning.

"...databases can be tuned by creating appropriate indexes, removing others, modifying the physical database schema to suit the most common types of queries, etc. So it isn't clear whether the PL/SQL figure could be better if the database was optimised by a good DBA."

While a good …

While the question of speed came up recently, it ties in to a long-standing position of mine. I ran some realistic benchmarks, and I'm much happier with my architecture now.

Background.

Years ago, at a Siebel conference, I heard a heretical comment. Specifically, they use the RDBMS as simple, flat …

In one case, the prospect had 7 interlocked databases, and wanted to do a technology upgrade. In other cases, the numbers was larger (up to 30, I think) but the problem was the same.

Essentially they said "It's taking us forever to rework this design. What should we do that …

The "correct" answer is to fully normalize the design and get away from a mixed bag of columns and nulls. The MESS is bad from every perspective, except query performance. A semi-normalized design that separates the STATE CHANGES from the ESSENTIAL DEFINITION is an optimal design in many respects.

Here …

Experimental results depend on details of the database server and the data model used. Actual application software may have other confounding problems that make these results less dramatic or more dramatic when applied to a existing application design.

I compared three table designs described in a previous posting Normalization Experiment …

Fragmentation & similar is sometimes a storage problem in I/O generated, vs. the gross space consumed. This distinction didn't leap out at me.

Performance degradation and storage expansion are closely related, but only for certain kinds of queries. Full table scans are penalized by sparsely used storage. Individual row retrievals …