Re: Storing data and code in a Db with LISP-like interface

> > > The RM is the pinnacle of data management.
.
>> That might be so but I need it spelt out to me. How is it relevant to games and ai? .
> The first thing that jumps to mind is "physical independence."

Since one can't find any RM implementations that are significantly hardware independent, this agrument shouldn't be offered. And in some gamming applications, performance requirements out weigh the need to have hardware independent software.

> Wouldn't you just rather write less code? If you could code at a higher level of abstraction (for much of the time) it would mean less code and more time spent on the problem domain.

One wouldn't necessarily want to write less code at higher level of abstraction, unless the consumer found the game's performance slower than a competitors.

> > Why would the RM be extended if it already covered everything?
.
> Ignorance, mostly. In some cases, philosophical differences. In a few rare cases, adding functionality (only logic databases would qualify for that, I would expect.)

Marshall, you are clue-less with respect to requirement for some types of gamming apps which make RM unsuitable.

> And anyway, I wouldn't say the RM is the best tool for *everything.* Just the best tool for data management.

... for a certain scope of applications. Any methodology that allows NULLs isn't the best.

> Oh, I see. These are requirements, eh? So I'm sure when you put the packaging together for your next game, it will trumpet "non-normalized data" and "OOP" on the cover? :-) Or perhaps these aren't requirements, but rather just the way you are used to doing things.

Normalization (of small amounts of data) and forcing highly variable data structures into rigid tables reduces performance and sprouts NULL faster than weeds in your front yard in spring, so when you market your "normalized" game, be sure to add "slow" in bold letters on the front of the box.

> And anyway, I disagree that you "don't want [your] data normalized."

It's not always a matter of wanting un-normalized data. Sometimes its a matter of wanting performance/flexiblity more than normalized data to make the game competitive in the market. Received on Sun Apr 30 2006 - 21:35:35 CEST