Re: Multiple specification of constraints

From: Marshall Spight <mspight_at_dnai.com>
Date: Sat, 13 Mar 2004 17:08:11 GMT
Message-ID: <%dH4c.104$KO3.4676_at_attbi_s02>

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news: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. :-)

LOL! Fair enough.

> > For one thing,
> > the operations shouldn't be limited to what's in memory any more than
> > the DBMS has that restriction.

>

> You could consider it like a distributed database, or like a transaction (in
> systems without multi-update capability). Synchronizing what's in the
> program's memory with the DB is no trivial matter, but it has been
> well-studied. Certainly it's no more difficult than the problem we have now,
> when the user goes to save and now we have to save their changes.

>

> > And what about things like keys?

>

> I'd love to have them, to be able to select objects by key rather than just
> hang on to it and pass it around via other object graphs.

Yes; they're a must-have.

> > 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.

I'm referring specifically to the key-allocation aspect. I mentioned hierarchies, not because they are hard to do (they aren't) but because that's a situation where you transition from not having keys to having keys, and they have to appear in two places. So if you have some legacy structure like (a(bc)) and you want to put it in your fancy new system that uses an application lanuage that's relational (as well as the backend store) then you have to come up with the keys from somewhere.

Table1: {key1, a}
Table2: { (key1, b), (key1, c)}

If you have thousands of such key allocation operations to do, it's important that it be a low-overhead operation. Certainly you *mustn't* send an rpc to a central authtority for each key.

> > How do we manage the key space in a client-server world?

>

> Good question. Possibly via "temp key" generation and then later
> replacement; possibly by acquiring blocks from the DB; possibly neither, if
> you have natural keys.

If you have natural keys, this is non-issue. I don't know what others' experience is, but I pretty much never have natural keys.

I don't think the "temp key" generation scheme would work, because once you've allocated the key, it has meaning (logical identity) and you can't just change its value without changing the meaning.

So that leaves block allocation and GUID generation as the two solutions I can think of. I guess that's okay.

> > 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...

Do what I did; go into management. :-)

Marshall Received on Sat Mar 13 2004 - 18:08:11 CET