does anyone have any advice (or links to resources) on LDAP design (specifically, when to use LDAP vs. when to use a RDBMS)
for example, say we wanted to utilize LDAP for this bulletin board in order to share the authentication details, etc...
would you create a custom schema for the whole shebang (ie, have all the bb data stored in a directory?) or perhaps just utilize an inetOrgPerson class for the main user info, and have everything else in a database, etc...?
i suppose my current thinking is that data which does not update, or needs to be shared over many resources generally benefit from being in a LDAP database, whereas application or resource specific data, or data that is constantly updated should be in a RDBMS?
Don't have any links but for advice I think using LDAP for a bb would work quite well, for me personally I'd go this way:
1. Store all user info in an LDAP server, this info doesn't get updated often so it's much of a concern.
2. Store all posts over a certain age in LDAP, ie if post older then 3 months move to LDAP.
Reasoning behind this is:
newer posts are either edited deleted or added to quite often, and this isn't what LDAP is designed for and could put a strain on the server, so use a RDB for this (I'd go with PostgreSQL).
3. If a a thread is replied to in less then 3 months it remains in the RDB and isn't archived over to the LDAP DB.
4. All posts that ARE archived are then locked and not able to be added to or edited or deleted (admin can of course).
This would provide a fast searchable bb, of course I think it would work best with a bb that is posted to with say "How Tos" or things like that where there is tons of info being put into it and this would be sort of an archive of all the info. This isn't thought out completely but I started thinking about it after having to get in and learn LDAP.
I'm starting to see how it can be used for much more then just user info. Right now I'm working on a project where we are going to store info about material produced basically a big library of information, and so far it works quite well in it and would be a big hassle to have used a RDB.
coolbeans, i suppose the thing to do is to actually just get in there and see what happens.
any advice on the intersection of ldap and a rdb though? specifically, i'm thinking if i have all user data in ldap, example:
cn: Me
userPassword: secret
uid: username
uidNumber: 501
someAttr: somevalue
and say a table on posts...
table_bb_posts (forum_id, uidNumber, post, date)
typically in a RDB environment you could quick run a join query to grab the userdata in addition to the post data... but now, i'm thinking the "best" way to handle it is to grab the ldap information then build the query around that.
i'm open to better implementations of the above though...
You'd want to get the post data first because otherwise you wouldn't know which usernames to get. Unless the post data is in the LDAP db in which case you'd still want to retrive the post data first then get the user info.
If you do decide to make a bb based off LDAP I for one would be intrested in seeing it, I don't have the time right now but I may think of making one in the future.
yep, i'll keep you informed, i may just hack up vbulletin or phpbb2 instead (to make it more useful to more people...) but then i'd have to keep up with new versions :(
Here is something I just found
http://www.jivesoftware.com/builds/docs/latest/ldap.html
Jive Forums that use LDAP as a backend
Originally posted by stuff two
any advice on the intersection of ldap and a rdb though? specifically, i'm thinking if i have all user data in ldap, example:
cn: Me
userPassword: secret
uid: username
uidNumber: 501
someAttr: somevalue
and say a table on posts...
table_bb_posts (forum_id, uidNumber, post, date)
typically in a RDB environment you could quick run a join query to grab the userdata in addition to the post data... but now, i'm thinking the "best" way to handle it is to grab the ldap information then build the query around that.
I'm interested in such implementation becoz this is what i'm going to do.
I have several applications using the same user database (it is an Access DB, my first one :). And these applications use several DBMS, including Access for old ASP apps, MySQL and eventually PostgreSQL for lastest PHP applications.
What I do at the moment is synchronize the tables in the Access database in each application DBs... not very smart, but that way I can easily join apps data whith user names and all...
Now I'd like to put user data in an LDAP directory to make it queryable from every app.
But there's a new problem, what is the best way to delete user data when a user is deleted from the LDAP directory?
And another one, let's say I have an app for booking. If I wanna know for each user what he has booked, first I query the DB :
select user_id, object_name, dat
FROM booking
And then the LDAP server to get each user name?
Now I'd like to know if such architecture for my problem is a good one or if there exist some better...
Thanks!
I have several applications using the same user database (it is an Access DB, my first one . And these applications use several DBMS, including Access for old ASP apps, MySQL and eventually PostgreSQL for lastest PHP applications.
What I do at the moment is synchronize the tables in the Access database in each application DBs... not very smart, but that way I can easily join apps data whith user names and all...
Now I'd like to put user data in an LDAP directory to make it queryable from every app.
How are you getting the log in information? If you use htaccess (and apache) you could use mod_ldap (http://httpd.apache.org/docs-2.0/mod/mod_ldap.html) if not just query the ldap server with whatever log in info is given and find the user in the ldap server.
But there's a new problem, what is the best way to delete user data when a user is deleted from the LDAP directory?
How would you be deleting from the LDAP directory? If manualy you could then do a DELETE query from the DB or if you have a script that deletes from LDAP have it also delete from the DB. And as a follow up have a script that runs daily/weekly that loops though all users in the LDAP directory and then deletes any that are in the DB that aren't in LDAP.
And another one, let's say I have an app for booking. If I wanna know for each user what he has booked, first I query the DB :
code:--------------------------------------------------------------------------------
select user_id, object_name, dat
FROM booking
--------------------------------------------------------------------------------
And then the LDAP server to get each user name?
I would query the LDAP server first then the DB. Loop through all users in your records and foreach user use that name in the DB.
select user_id, object_name, dat
FROM booking
WHERE user_id = '[user_id]'
If any of this isn't clear please say so :)
i think you are encountering the same "oddness" (for lack of a better word) about it as i was.
but i think a good comparison is the file system. the file system is similar to an LDAP database in that it's hierarchical
now imagine you're making a simple gallery system. you probably don't want to store the actual image in the db (although you could, but may as well leave the file system there for what it's good at :) )
so in essence, you point from the DB to a location on the file system. any updates you do must be done to both the file system and DB.
LDAP is no different, the two calls need to be made. i hope that made sense... :)