db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <aok...@bellsouth.net>
Subject Re: [Apache Incubator Directory Proposal] From the incubator list
Date Thu, 11 Sep 2003 20:25:07 GMT
Good point Robb.  LDAP needs a database to operate (its an access protocol) 
and is not a database in itself.  
> From: Robb Penoyer <rpenoyer@timgia.com> 
> Date: 2003/09/11 Thu PM 03:29:02 EDT 
> To: general@db.apache.org 
> CC: aok123@bellsouth.net 
> Subject: [Apache Incubator Directory Proposal] From the incubator list 
> 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 
>     - 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 <brianm@apache.org> 
> To: general@incubator.apache.org 
> 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 
> >>general@db.apache.org 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 
> >in their foundation, which is completely incompatible with the ASF 
> >meritocracy. 
> > 
> >There there are ODBMS such as Ozone (wrong license, though). 
> From: <aok123@bellsouth.net> 
> To: <general@incubator.apache.org> 
> CC: <general@db.apache.org>, <rpenoyer@timgia.com>, 
>          <ldapd-devel@lists.sourceforge.net> 
> 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 
> really. 
> Actually the combination of an RDBMS coupled with an LDAP server would be 
> powerful together.  If the data dictionary of an RDBMS is stored in LDAP the 
> schema remains consistant across RDBMS instances and can be managed 
> and replicated easily.  Also works nicely for the storage of simple LUT 
> 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 
> 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 
> 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.  
> 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.  
> 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 <mccallister@forthillcompany.com> 
>  > Date: 2003/09/11 Thu PM 12:27:01 EDT 
>  > To: general@incubator.apache.org 
>  > Subject: Re: Official Apache Directory Project Proposal Submission 
>  > 
>  > Am writing up a post, but you might also want to say something about 
>  > this on general@db.apache.org as an LDAP is sort of a db =) 
>  > 
>  > A high-profile new project could help liven up DB some ;-) 
>  > 
>  > -Brian 

View raw message