Re: Database vs Directory Service

[Ron Chmara <ron@opus1.com>]

Arnold Shore wrote:
> I think we need to keep both, rendering unto Caesar ... .  That is, retain
> the inherent directory information/schema where it is, and also provide a
> linkage mechanism to the RDBMS data.  A GUID

(Global user ID, I assume... a db "key" across each)

> appears key to doing that
> effectively, extending both schema to accommodate that item.  The overall
> application would draw on both information sources for end-user interaction,
> presenting a unified appearance.
> I'll appreciate hearing the thoughts/opinions/experiences/recommendations of
> anyone with some insights here.  Thanks, people.

It's surprisingly standard to have both. With "plans" to normalize.... that
*never* seem to be completed. "Maybe next year". ;-)

The key to making this work is to either use a master/slave mentality (update
one, which repopulates the other) or to make any add/edit/delete from end users
work with both at the same time.

As far as "unified appearance", that doesn't really have much to do with the
underlying technologies if you're using web interfaces. If you are supporting
a great number of legacy, RDBMS, GUI or CLUI, interfaces, it's much harder
to add LDAP unless you design a new UI for both, or just slave the LDAP data in some
way. If you're tied into some proprietary systems for either set of interfaces,
a triggered re-populate/update can be much easier in the short run... at
the cost of propogation delays.

-Bop

--
Personal:  ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/
Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not neccesarrily those of myself,
my  employers, or any of the other little voices in my head.