Forgive the cutting and pasting of the mail notes below - but that is the background. I really wanted to respond to Brian, and since Alex mentioned my name.
LDAPd is a java implementation of and v3 compliant LDAP server, and hopefulyl will soon enter the Apache Incubator as the/part of the Apache Directory candidate.
In the classical sense, LDAP really isn't a database, but it needs one to work - like everything else in the world. the primary difference is transactions, it doesn't have any, nor do the standard require them. To make LDAP work efficiently, a high performance on read operations becomes the focus.
LDAP and databases (relation, oo or other) do have several factors in common,
- client and server side providers
- system organizational areas, system tablespaces, system backends, schema management, security, authentication...
Where LDAP has a edge is in the somewhat static "lookup" space. Being optimized for read operations, handling id to value management falls into it's sweet spot. A well designed relational DB is much more suited for the transactional type data.
Can LDAP and transactional database technology leverage each other - absolutely. The architectural overlap is fairly astounding, and has bee the topic of many discussions in the LDAPd community. Consider a highly tuned LDAP server responsible for database schema administration (normally static information).
Advantages: LDAP protocol requires replication and the ability forward requests, which are not available locally, to a location which can serve them. So the ability to manage distributed databases becomes a natural component. With more thought put in place, there really is no reason that with LDAP serving as the system engine for a database, you couldn't have storage managers optimized for object persistence (oodb), transaction data (rdbms), and hierachical information (hierarchical db) all acting as one database system.
I could go on for a very long time .....
From: Brian McCallister <[EMAIL PROTECTED]> To: [email protected] X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
I wasn't so much looking for projects to put under the DB wing, but thinking of people who might be interested in LDAPd. An LDAP most definately is *not* an RDBMS, but it is a protocol for accessing hierarchical databases. After filesystems and DNS, ldap's are probably the most widely used hierarchical databases around.
I for one would be more than happy to contribute LDAPd, particularly if said alternative is Java embedable.
So, if it comes to a vote and I am allowed to vote, it has my +1.
-Brian
On Thursday, September 11, 2003, at 02:26 PM, Noel J. Bergman wrote:
you might also want to say something about this on [EMAIL PROTECTED] as an LDAP is sort of a db =)
A high-profile new project could help liven up DB some ;-)
I think that naming and directory services are sufficiently different from an ODBMS or RDBMS.
DB might want to consider adopting Jakarta Commons DBCP. That topic has come up before, and didn't lack support.
There are some other candidates that the DB PMC could look into incubating and adopting. For example, http://axion.tigris.org/ is a rather obvious candidate, especially considering the committer list (geir jvanzyl mpoeschl rwald).
Firebird would be nice, but they seem more interested in selling memberships in their foundation, which is completely incompatible with the ASF meritocracy.
There there are ODBMS such as Ozone (wrong license, though).
From: <[EMAIL PROTECTED]> To: <[email protected]> CC: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: Re: Re: Official Apache Directory Project Proposal Submission Date: Thu, 11 Sep 2003 14:24:29 -0400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
Brian,
Actually we have implemented a rudimentary relational database (non-sql) inside the server specifically to optimize for LDAP, however the engine core could be reused for an RDBMS. Both and RDBMS and an LDAP server are databases really.
Actually the combination of an RDBMS coupled with an LDAP server would be very powerful together. If the data dictionary of an RDBMS is stored in LDAP the schema remains consistant across RDBMS instances and can be managed centrally and replicated easily. Also works nicely for the storage of simple LUT based contraint tables. You know the ones u use for an enumeration of options to constrain a column. For example a LOAN table may have a TYPE column and there may be a LOAN_TYPES lookup table to constrain the column containing a single pk column of loan type varchars like so:
Jumbo 30 Year Fixed 15 Year Fixed 5 Year ARM
etc ...
LDAP would be great for storing LUT's where the reads are many and the writes are few. It's not a core table for transactions like the LOAN table itself. This way several databases can leverage the same LUT data consistantly. Also you can use delegation in LDAP to let the designated authority manage the additions to the LOAN_TYPES table.
Another member on the LDAPd team named Robb which is CC'ed in this email has been discussing the potential for a common database library. The library would have a storage managment layer, a index and a search engine with an optimizer for use in any database paradigm.
Robb's an ex Oracle developer that helped design what is to be the system catalog for LDAPd. He's valuable to us from a db engineering standpoint. I'm sure he could play a pivitol role in working with the db folks. But please don't take him from us just yet ;-).
BU, Alex
> > From: Brian McCallister <[EMAIL PROTECTED]> > Date: 2003/09/11 Thu PM 12:27:01 EDT > To: [email protected] > Subject: Re: Official Apache Directory Project Proposal Submission > > Am writing up a post, but you might also want to say something about > this on [EMAIL PROTECTED] as an LDAP is sort of a db =) > > A high-profile new project could help liven up DB some ;-) > > -Brian
