Re: Database Selection...
Hunter Matthews <[email protected]>
| Newsgroups | gmane.network.up2date.current.devel |
|---|---|
| Message-ID | <1013528240.8876.72.camel@jade> |
On Mon, 2002-02-11 at 20:24, Thornton Prime wrote: > > On 11 Feb 2002, Hunter Matthews wrote: > > > I know this was meant half humorously (at least I hope it was), but I > > thought about this (I'm working on LDAP for my department here), and I > > doubt LDAP could handle the kind of data we are talking about here. > > (IE, think about a "client" object with 700 "package" values, or a > > client object with 700 children) > > I'm completely serious. RedHat uses Novell eDirectory for their RHN, I > believe. No longer: LDAP, even the fastest LDAP (novell I believe still has that title) could not keep up. The word is that it is entirely oracle based now. But note that edir was ONLY used for auth - even when they used it, all the rpm/channel/dependancy data was in oracle. > OpenLDAP may be the wrong choice, but even then I believe U Mich had an > authentication server with over 20K objects that it searched on with every > login. It is all about picking the right indecies. > > > However, once 1.1 opens up (which will be the "database" devel version), > > you're more than free to try it. :) > > I will certainly give it a whack. > > LDAP is very different than SQL, though, so the database abstraction layer > will need to be very abstract. Toby's patch uses the python v2 DB API. If the LDAP connection stuff supports it, YAY. If not, I will very much want to see a very clean patch before applying it. At this point, I think everyone needs to work on making the base 1.1 (postgres) server as stable and sane as possible, THEN work on alternative database backends. > > thornton > > _______________________________________________ > Current-server mailing list > [email protected] > http://lists.dulug.duke.edu/mailman/listinfo/current-server > > -- Hunter Matthews Unix / Network Administrator Office: BioScience 145/244 Duke Univ. Biology Department Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438 Never take candy from strangers. Especially on the internet.