Re: Multiple specification of constraints
Date: Thu, 11 Mar 2004 22:21:35 GMT
Message-ID: <PD54c.57854$GB2.34661_at_newssvr33.news.prodigy.com>
"Marshall Spight" <mspight_at_dnai.com> wrote in message
news:6124c.9096$YG.81835_at_attbi_s01...
> "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
news:Exn1c.20851$mK4.3170_at_newssvr31.news.prodigy.com...
> >
> > Agreed. And if we had languages that supported relations for all
processing,
> > we wouldn't be in the O-O mess we're in now. It would be just amazingly
> > useful to be able to perform relational operations on data in memory...
and
> > then, at the end when satisfied, persist it.
>
> Okay, that sounds great and all, but how's it going to work?
Hey, dude, this is theory. :-)
> For one thing,
> the operations shouldn't be limited to what's in memory any more than
> the DBMS has that restriction.
> And what about things like keys?
> Let's say we want to migrate some hierarchically-stored data into
> our RDBMS, how do we make that work?
I don't follow - that's not a hard thing to do. Besides, I'm talking about having not hierarchies (object graphs), but actual relations in memory.
> We need to have the
> foreign keys, which means we need to allocate keys for every tuple.
True.
> How do we manage the key space in a client-server world?
> Do the
> keys in the data have to be unique before they're insterted?
I would assume so.
> How do we enforce that in a distributed environment?
Dunno. How do cell phone carriers allocate phone numbers and now shuffle them around between services? I suspect this has also been studied. Ideas? I'm brain-dead right now after staring at the most horrific Java code ever written all day long...
- Eric