> developer > dnu > courses > beginning eDirectory page 2

eDirectory for the Beginner

February 2002

DeveloperNet University Course

Reader Rating    from ratings

Directory or Database?

First, eDirectory is a database, so why not just use a relational database?

• What's the difference?
  
  
• When do you use one over the other?
  
  

Figure 1: The directory db- a hierarchical object-oriented information model, and the relational db- a relational data model.

These basic differences manifest themselves as important architectural differences between directories and databases.

Relational Databases

Provide referential integrity across relational tables and concurrency control with file and record locking. Are best when... (examples: airline reservations, banking, ticket purchasing) data changes rapidly- ratio of writes to reads is high multiple clients attempt simultaneous updates changes to data must be instantly available transactional integrity is top priority

Directory Services

Provide a loosely consistent data model. Directories permit segregated updates to directory data and then use replication and synchronization protocols to resolve conflicts. In this way, the directory can distribute information, updating it in many locations and presenting multiple views of the information which rdbs don't support. Best when... (examples: address books, user security, resource management) hierarchical structure makes sense ratio of reads to writes is high fast searches important data available to many people in different locations schema modifications are needed

Both have different roles in the computing industry. Even though each has its own strengths and weaknesses, they are both important. Basically, relational databases are good choices for applications in which there's a high ratio of writes to reads, data changes rapidly, multiple clients attempt simultaneous data updates, and any changes to the data must be instantly available to all clients. Directory services provide fast read operations, making them ideal for applications that must find resources or publish data to large numbers of users in many different locations while maintaining that data in a loosely consistent state. Directories are also the ideal infrastructure for centralizing user, resource, and security management.

Managing users, resources, and security policies are roles for which the directory is ideally suited, for example.

In conjunction with general-purpose security services, directories can provide these functions for many applications, reducing the overhead associated with managing each application individually.

Yet applications that require very consistent information models, such as inventory management, simply can't rely on the directory's loosely consistent and highly distributed architecture. Directories lack the general-purpose transaction functions and consistency capabilities-operating within a relational data model- that these applications need.

There are also vendors who use a relational database to store the directory object information for their LDAP server- they still are considered a directory. This is done by mapping the directory objects to the relational database tables. This means all searches, adds, mods, etc. commands have to be translated and mapped to SQL statements for the relational database which could effect performance.

So a solution may not be which one to use, but the architecture to support both technologies may be needed.