数据库 – 使用LDAP服务器作为存储基础,它有多实用?

我想学习使用LDAP服务器(比如AD)作为存储基础的实用性.更清楚;使用LDAP服务器而不是使用RDBMS存储数据有多大意义?

我猜你大多数人可能会说“它没有”,但可能有一些理由让它变得有意义(特别是商业明智);

先点几点;

>每个表都成为一个容器实体,每一行都成为一个新的实体.行实体包含列的属性.所以你用这种方式表示你的数据. (这应该是我认为最有意义的表示,欢迎提出建议)
>因此可以像数据库服务器一样存储数据,但缺少FK和PK(不确定PK)支持是一个问题.另一方面,它支持属性(与列相关)索引(不确定效率如何).因此,数据的一致性是应用程序层的责任.

为什么有人会这样做?

>应用程序使用/存储的数据与AD中的现有数据紧密匹配. (用户,机器,部门信息等)(但现有实体模式仍需要一些自定义,并且对于不太相关的数据,需要新的模式定义.)
>(我认为最强的理由是:业务相关)大多数中型公司都配置了很好的AD服务器(复制,备份等),但他们没有这样的数据库设置(您可以对此进行评论)就像你想要的那样).假设当您销售需要为这些公司设置数据库的软件时,他们必须管理他们的数据库设置;但如果你说“你不需要数据库设置和管理;你可以只使用现有的AD”,这听起来很吸引人.

显然,放弃使用DB有许多缺点,请随意提及它们,但我们假设它们是可以接受的. (如果问题不够明确,我可以提及更多.)

LDAP是维护大多数业务数据的糟糕工具.

想想典型的一对多关系 – 比如客户和订单.一个客户有很多订单.

没有好的方法在LDAP目录中表示此数据.

您可以通过使该给定对象类的每个条目都具有“外键”属性来尝试使用模拟“外键”,但您的参照完整性刚刚超出窗口.级联删除是不可能的.

您可以尝试拥有“订购”子项的“客户”对象.但是,您刚刚介绍了一个特定的层次结构 – 您现在已经与之相关联了.

这是最简单的用例.一旦开始涉及更复杂的关系,您基本上就是在为不同目的而设计的系统明确中重新发明RDBMS.名称 – 目录中的线索.

如果您要存储电话簿,请确保使用LDAP.除此之外,使用真正的数据库.

相关文章
相关标签/搜索