ADAM和AD以及关系数据库

如果使用微软系统，原来组织内部已经有了一个微软的AD域环境，需要一个提供LDAP访问支持的数据存储，里面是一些自定义对象，应该怎么做呢？

有这么几个选择：

1。在公司原来的AD上面做Schema扩展，定义新应用需要的对象，参考这篇文章

 http://technet2.microsoft.com/windowsserver/en/library/8196d68e-776a-4bbc-99a6-d8c19f36ded41033.mspx?mfr=true

这样做的好处是不需要新的服务器，不好的地方就是需要修改原来AD的schema，即使原来是一个多域环境也是一样，应为修改schema是一个森林级别的操作，这样做一不小心就破坏了原来的AD，而且复制等等都和原来AD的复制掺和在一起了

 2。多森林，为新的应用建立一个新的森林

这样做的缺点显而易见，你需要安装新的域控制器，维护一套新的AD，有点大材小用的感觉

而且，很有可能会涉及两个森林的资源访问，比如你的应用使用集成认证，主机在你原来的森林中，用户也是，可是需要访问新的森林中的资源，这就涉及到DNS转发，森林的信任等问题，可以参考这篇文章

http://www.microsoft.com/china/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/mtfstwp.mspx

 3。用ADAM

http://technet2.microsoft.com/windowsserver/en/library/4f143ef3-e0f3-4065-bfd0-6117262fdc7f1033.mspx?mfr=true

 ADAM（Active Directory Application Mode）就是一个和AD结构非常相似的轻型的目录服务，使用它最大的好处就是简单，它和AD最大的区别

就是AD需要域控制器，ADAM是安装在操作系统上面的一个service。

AD和DNS集成，ADAM就是一个服务，和DNS关系不大
所以，ADAM就是简单。

 

它和关系型数据库最大的区别在于（其实主要是类似AD和关系型数据库的查询）：

类似AD的强大的复制功能

LDAP查询支持，非常好的查询性能，但是不适合频繁修改

数据的层次关系非常强，比如一个组织的多层次结构等等

如果大量使用交易，修改等等的OLTP系统，不适合使用

 

所以，这样看起来，ADAM就好像是一个AD和关系数据的折中，是一个提供了很好的复制功能的，支持LDAP查询的数据库。