July 25, 2008 at 5:16 am
Not sure if this is precisely the forum for this kind of question but I'm sure I'll be advised as to that.
I've been tasked with looking into how, or indeed if, my company's Making Contact/Personnel/HR (call them what you will) systems might be linked to Active Directory instead of, as is currently the case, a SQL Server database (several SQL Server databases in fact). Personally I'm not convinced.
Active Directory is certainly useful. Obviously it's the primary resource for user's Windows accounts and passwords and has the facility to also hold useful HR info - e.g. Names and Addresses, Telephone Numbers, some Organizational data. However my company, probably like most peoples, has a sometimes complicated hierarchical structure difficult to replicate in AD. Additionally AD is highly denormalised so searching can be complciated and inefficient. On the other hand we use Groupwise as an e-mail system and it has proved difficult to sync e-mail addresses between Groupwise and the HR databases so these are sometimes incorrect or out-of-date. (Although we shall shortly be moving to Exchange). So holding datab like that in AD could be useful.
I was thinking maybe a composite of the two might be a possible solution - e.g. use AD for basic, atomic data like Name, Sex, Marital Status, etc - and retain SQL Server for the rest, linked I guess by the Employee ID currently used in HR databases. Queries would then include an LDAP component to them.
I would very much welcome the views and advice of others who might have faced the same dilemmas.
Regards,
YaHozna.
July 25, 2008 at 6:09 am
For awhile, we have a combination of some things stored in AD and almost everything else stored in databases (primarily Oracle, actually). All of the data has pretty much been pulled out of AD and put into tables and we have a synchronization process that runs. We keep GUIDS for the sync process and this has even become a problem because our development environment has different AD GUIDS.
It sounds reasonable in the beginning to use AD as a data store for user information, but it becomes really hard to use. You can index columns in AD so it is actually pretty quick to search, but who is going to write all of these LDAP queries? Then, you get a request to include the username and email address in a report - great - running an LDAP query in reporting services is a lot of fun.
Finally, you need a development environment. We are a pretty big company with a lot of resources. We don't maintain two AD structures so we can test our applications. It is pretty impractical to maintain.
So, I would typically recommand against it. If you could use the CLR and write a bunch of code to allow you to access the AD information through your SQL Server, I think it could be made easier, but a simple synchronization process will be far easier to write and maintain.
July 25, 2008 at 7:18 am
Michael, many thanks for the input. Food for thought.
Regards,
YaHozna.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply