Re: Multiple specification of constraints

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:%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...
> > Hey, dude, this is theory. :-)
>
> LOL! Fair enough.

I guess that's the nice default fallback position in this group...

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

Good point. For such things in O-O languages, I'll usually have a Manager or DAO object that gives me new instances, which allows it to do whatever block allocation it needs to do, talk to the server when it needs to, etc. Plus it gives a nice place for the heinous "new" keyword - one of the roots of all programming evil. Great, give us a language with polymorphism EXCEPT for where it really counts...

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

On the other hand, since it's not a natural key, its value is arbitrary. I sort of agree that you can't change the value - if it's in a hierarchy, presumably that key value is encapsulated until you break open the hierarchy, and could be changed at will. But then I suspect you're talking about the point at which a hierarchy has to be opened anyway...

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

D'oh! Been there, done that, didn't buy the T-shirt because it didn't fit and was itchy.

• Eric