Re: foundations of relational theory? - some references for the truly starving

"Bob Badour" <bbadour_at_golden.net> wrote in message news:0c6cnW994f01HgeiXTWJkQ_at_golden.net...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:B6nmb.22188$e01.46207_at_attbi_s02...
> >
> > I suspect Costin is not a native speaker of English. While he
> > is, in fact, jaw-droppingly educated as near as I can tell, his
> > diction is idiomatic in a way that sounds distinctly non-native
> > to me, an American.
>
> Je pense que le singe ridicule est français.

J'ai toujour pense qu'il etait italien, mais je ne parle pas cette langue. Sorry, ASCII only. :-)

> > In fact, I can imagine situations where I *wouldn't*
> > need persistence but I would want a DBMS. If
> > I was crunching up a bunch of numbers and was
> > happy to restart upon a crash, say.
>
> I expect this is what "in-memory" dbmses are for.

Sure. Although I ususally hear in-memory DBMSs described in context as a performance technique. One might use an in-memory DBMS but still have an on-disk logfile, and want to persist the data.

The somewhat odd point I was making was that, given the importance of integrity enforcement, a DBMS could be useful at runtime, within an application, even if one *never* intended to persist the data therein. Declarative integrity constraints kick ass over every existing procedural technique that tries to do the same thing, such as input validation, asserts, or unit or system test suites. They are even superior (in the sense of being more comprehensive) than
static type inferencing systems, and that's saying a lot.

A really crippling meme out there is that DBMSs are for persistence *and nothing else.* I try to counter that meme when I run into it, and imagining a useful DBMS that didn't even *have* persistence strikes me as a powerful technique to that end.

Marshall Received on Sat Oct 25 2003 - 18:10:16 CEST