|
Hi,
I'll answer in the
message.
I sincerely doubt it's entirely the openLDAP server code. Oracle probably took their lead from them, but I'm sure they optimized it for their database. LDAP and a relational database are two highly different ways of organizing information. Trying to stuff a relational model into a hierarchical model (LDAP) for starters can easily make you go mad. You really have to understand how both work to have any chance of success (which is why it makes sense for Oracle to try such a thing and not yourself unless you happened to be named Informix or IBM). This is a similar problem we faced when trying to fit objects (which also follow a hiearchical data fashion) into a RDBMS. From what I've read OID (the name of Oracle's server) is not nearly as quick or scalable as a native LDAP directory such as Iplanet (formerly Netscape ) or even Novell's NDS 8. You have to realize that a directory and a RDBMS are also trying to solve two different goals. LDAP is designed for extremely fast reads, can be distributed and can handle if the data goes out of synch for a while (e.g. it's usually ok that your address doesn't change in the LDAP server immediately after you move, just as long as it updates in a relatively short period of time). LDAP is also designed to be transactional on the atomic level (e.g. each operation succeeds or fails on its own without depending or affecting previous/future operations). A RDBMS is designed to be an equal performer in reads/writes (e.g. neither is exceptionally fast or slow). It's also designed to handle massive transactions (e.g. each operation success/failure can affect the outcome of many previous/future operations). This is why you want your bank account to be stored in a RDBMS because of it's transactional recovery features. Thus it can be said it's not easy to simply drop in a RDBMS enabled directory server (such as OID) and expect it to work with your existing data. I haven't talked to anyone who's ever used OID, but if it was as easy as just installing it to turn your existing databases into LDAP enabled date depositories, I think there would be more people talking about it. Instead you need to begin to think about how to organize your organization around a directory service. A directory service will not replace your RDBMS, just as your RDBMS is not a replacement for a directory service. They are two major infrastructure tools for your network environment. Future technologies such as DSML (Directory Service Markup Language see www.dsml.org) will make it easier to pass data from one system to another. Metadirectory tools will also help out. Secondly how ldap and e-commerce are related? Can somebody give me a good pointer on various LDAP is useful to store demographic information, such as names, addresses, credit card numbers, passwords etc. This stuff doesn't change often (LDAP updates do a take a long time) but needs to be read a lot and accessed quickly. LDAP is also important because of its open standard and native TCP/IP implementation. This means that it can easily be accessed from many different systems, something that is not true (at least not easily done) with an RDBMS. Stuff that changes often and, more importantly, needs strong transactional support such as inventory control, probably is better suited for a RDBMS. e-commerce products that use ldap and how does the relational database as a backend Well the problem with this is that most e-commerce systems are developed in house or under strict NDAs so hard to really tell you. Though I would point out that Netscape's NetCenter portal uses LDAP. Probably the best example of how a directory can enable e-commerce is the Novell www.digitalme.com project. Basically you can store all of your information in a Novell directory (which is LDAP compliant). Then you can select which parts of that data are given to different sites. advantageous(if it is!!). If anyone of you is planning on this direction and can throw some light without Well I don't have any benchmarks to show you. But if you look at the major LDAP developers write now: Iplanet (e.g. Netscape/Sun Alliance) Novell openLDAP None of these use a RDBMS as their default back-end. If a RDBMS was the best way to go, then Netscape would have made a deal with Oracle, Informix, etc. to include those products as their default back-end. Instead they licensed SleepyCat's Berkeley DB (while Sleepycat is opensource, you do have to pay fee to use it commercially) because of it's performance (but with reliability that can rival even the big RDBMS such as Oracle). BDB is usually regarded as one of the fastest db's around and Netscape still does its own tricks to get the most out of the server. Netscape has 3 of the original LDAP authors so it's not like they don't know what their doing when it comes to LDAP. violating patents, copyrights or confidentiality it would be really helpful to me. Well luckily I work in education so I can talk pretty freely :). Whew. Mark
|