MSSQL编程：先容ldap

使为了数据安全，我们搭建了主从。但实时主从备份只能防止硬件问题，比如主库的硬盘损坏。但对于误操作，则无能为力。比如在主库误删一张表，或者一个update语句没有指定where条件，导致全表被更新。先容LDAP
原文：http://ldapman.org/articles/intro_to_ldap.html

原文MichaelDonnelly

翻译：Brimmer

假如你在盘算机行业事情，那末对LDAP大概早有耳闻了。想深切地懂得LDAP吗？那末能够好好地读一下这篇文章。这篇先容性的文章是一系列先容怎样在企业中计划、完成和集成LDAP情况的文章的头一篇。次要是先让你熟习一下LDAP的基础观点，那些对照坚苦的细节成绩将放到今后会商。在这篇文章中我们将要先容：

甚么是LDAP?

甚么时分该用LDAP存储数据？

LDAP目次树的布局

独自的LDAP纪录

作为例子的一个独自的数据项

LDAP复制

平安和会见把持

如今LDAP手艺不但开展得很快并且也是冲动民气的。在企业局限内完成LDAP可让运转在几近一切盘算机平台上的一切的使用程序从LDAP目次中猎取信息。LDAP目次中能够存储各类范例的数据：电子邮件地点、邮件路由信息、人力资本数据、公用密匙、接洽人列表，等等。经由过程把LDAP目次作为体系集成中的一个主要环节，能够简化员工在企业外部查询信息的步骤，乃至连次要的数据源都能够放在任何中央。假如Oracle、Sybase、Informix或MicrosoftSQL数据库中已存储了相似的数据，那末LDAP和这些数据库究竟有甚么分歧呢？是甚么让它更具上风？请持续读下往吧！
甚么是LDAP?
LDAP的英文全称是LightweightDirectoryAccessProtocol，一样平常都简称为LDAP。它是基于X.500尺度的，可是复杂多了而且能够依据必要定制。与X.500分歧，LDAP撑持TCP/IP，这对会见Internet是必需的。LDAP的中心标准在RFC中都有界说，一切与LDAP相干的RFC都能够在LDAPmanRFC网页中找到。
怎样利用LDAP这个术语呢？
在一样平常扳谈中，你大概会听到有些人这么说：“我们要把那些器材存在LDAP中吗？”，大概“从LDAP数据库中掏出那些数据！”，又大概“我们怎样把LDAP和干系型数据库集成在一同？”。严厉地说，LDAP基本不是数据库而是用来会见存储在信息目次（也就是LDAP目次）中的信息的协定。更加切实和正式的说法应当是象如许的：“经由过程利用LDAP，能够在信息目次的准确地位读取（或存储）数据”。可是，也没有需要隐恶扬善，只管表达得不敷正确，我们也都晓得对方在说甚么。
LDAP目次是数据库吗？
就象Sybase、Oracle、Informix或Microsoft的数据库办理体系（DBMS）是用于处置查询和更新干系型数据库那样，LDAP服务器也是用来处置查询和更新LDAP目次的。换句话来讲LDAP目次也是一品种型的数据库，可是不是干系型数据库。不象被计划成每分钟必要处置成百上千条数据变更的数据库，比方：在电子商务中常常用到的在线买卖处置（OLTP）体系，LDAP次要是优化数据读取的功能。
LDAP目次的上风
如今该说说LDAP目次究竟有些甚么上风了。如今LDAP的盛行是良多因数配合感化的了局。我在这里说的不外是一些基础的缘故原由，请你注重一下这不外是一小部分缘故原由。

大概LDAP最年夜的上风是：能够在任何盘算机平台上，用很简单取得的并且数量不休增添的LDAP的客户端程序会见LDAP目次。并且也很简单定制使用程序为它加上LDAP的撑持。

LDAP协定是跨平台的和尺度的协定，因而使用程序就不必为LDAP目次放在甚么样的服务器上费心了。实践上，LDAP失掉了业界的普遍承认，由于它是Internet的尺度。产商都很乐意在产物中到场对LDAP的撑持，由于他们基本不必思索另外一端（客户端或服务端）是怎样的。LDAP服务器能够是任何一个开辟源代码或商用的LDAP目次服务器（大概还多是具有LDAP界面的干系型数据库），由于能够用一样的协定、客户端毗连软件包和查询命令与LDAP服务器举行交互。与LDAP分歧的是，假如软件产商想在软件产物中集成对DBMS的撑持，那末一般都要对每个数据库服务器独自定制。

不象良多商用的干系型数据库，你不用为LDAP的每个客户端毗连也许可协定付费。

年夜多半的LDAP服务器安装起来很复杂，也简单保护和优化。

LDAP服务器能够用“推”或“拉”的办法复制部分或全体数据，比方：能够把数据“推”到远程的办公室，以增添数据的平安性。复制手艺是内置在LDAP服务器中的并且很简单设置。假如要在DBMS中利用不异的复制功效，数据库产商就会要你付出分外的用度，并且也很难办理。

LDAP同意你依据必要利用ACI（一样平常都称为ACL大概会见把持列表）把持对数据读和写的权限。比方，设备办理员能够有权改动员工的事情地址和办公室号码，可是不同意改动纪录中别的的域。ACI能够依据谁会见数据、会见甚么数据、数据存在甚么中央和别的对数据举行会见把持。由于这些都是由LDAP目次服务器完成的，以是不必忧虑在客户真个使用程序上是不是要举行平安反省。

LDAP关于如许存储如许的信息最为有效，也就是数据必要从分歧的地址读取，可是不必要常常更新。比方，这些信息存储在LDAP目次中是非常无效的：

l公司员工的德律风号码簿和构造布局图

l客户的接洽信息

l盘算机办理必要的信息，包含NIS映照、email化名，等等

l软件包的设置信息

l公用证书和平安密匙
甚么时分该用LDAP存储数据？
年夜多半的LDAP服务器都为读麋集型的操纵举行专门的优化。因而，当从LDAP服务器中读取数据的时分会比从专门为OLTP优化的干系型数据库中读取数据快一个数目级。也是由于专门为读的功能举行优化，年夜多半的LDAP目次服务器其实不合适存储必要必要常常改动的数据。比方，用LDAP服务器来存储德律风号码是一个很好的选择，可是它不克不及作为电子商务站点的数据库服务器。

假如上面每个成绩的谜底都是“是”，那末把数据存在LDAP中就是一个好主张。

l必要在任何平台上都能读取数据吗？

l每个独自的纪录项是否是每天都只要很少的改动？

l能够把数据存在立体数据库（flatdatabase）而不是干系型数据库中吗？换句话来讲，也就是不论甚么范式不范式的，把一切器材都存在一个纪录中（差未几只需满意第一范式）。

最初一个成绩大概会唬住一些人，实在用立体数据库往存储一些干系型的数据也是很一样平常的。比方，一条公司员工的纪录就能够包括司理的登录名。用LDAP来存储这类信息是很便利的。一个复杂的判别办法：假如能够把保数据存在一张张的卡片里，就能够很简单地把它存在LDAP目次里。
LDAP目次树的布局
LDAP目次以树状的条理布局来存储数据。假如你对自顶向下的DNS树或UNIX文件的目次树对照熟习，也就很简单把握LDAP目次树这个观点了。就象DNS的主机名那样，LDAP目次纪录的标识名（DistinguishedName，简称DN）是用来读取单个纪录，和回溯到树的顶部。前面会做具体地先容。

为何要用条理布局来构造数据呢？缘故原由是多方面的。上面是大概碰到的一些情形：

l假如你想把一切的美国客户的接洽信息都“推”到位于到西雅图办公室（卖力营销）的LDAP服务器上，可是你不想把公司的资产办理信息“推”到那边。

l你大概想依据目次树的布局赐与分歧的员工组分歧的权限。鄙人面的例子里，资产办理组对“asset-mgmt”部分有完整的会见权限，可是不克不及会见别的中央。

l把LDAP存储和复制功效分离起来，能够定制目次树的布局以下降对WAN带宽的请求。位于西雅图的营销办公室必要每分钟更新的美国发卖情况的信息，可是欧洲的发卖情形就只需每小时更新一次就好了。
寻根究底：基准DN
LDAP目次树的最顶部就是根，也就是所谓的“基准DN”。基准DN一般利用上面列出的三种格局之一。假定我在名为FooBar的电子商务公司事情，这家公司在Internet上的名字是foobar.com。

o="FooBar,Inc.",c=US

（以X.500格局暗示的基准DN）

在这个例子中，o=FooBar,Inc.暗示构造名，在这里就是公司名的同义词。c=US暗示公司的总部在美国。之前，一样平常都用这类体例来暗示基准DN。可是事物老是在不休变更的，如今一切的公司都已（或企图）上Internet上。跟着Internet的环球化，在基准DN中利用国度代码很简单让人发生搅浑。如今，X.500格局开展成上面列出的两种格局。

o=foobar.com

（用公司的Internet地点暗示的基准DN）

这类格局很直不雅，用公司的域名作为基准DN。这也是如今最经常使用的格局。

dc=foobar,dc=com

（用DNS域名的分歧部分构成的基准DN）

就象下面那一种格局，这类格局也是以DNS域名为基本的，可是下面那种格局不改动域名（也就更容易读），而这类格局把域名：foobar.com分红两部分dc=foobar,dc=com。在实际上，这类格局大概会更天真一点，可是关于终极用户来讲也更难影象一点。思索一下foobar.com这个例子。当foobar.com和gizmo.com兼并以后，能够复杂的把“dc=com”看成基准DN。把新的纪录放到已存在的dc=gizmo,dc=com目次下，如许就简化了良多事情（固然，假如foobar.com和wocket.edu兼并，这个办法就不克不及用了）。假如LDAP服务器是新安装的，我倡议你利用这类格局。再请注重一下，假如你盘算利用举动目次（ActriveDirectory），Microsoft已限定你必需利用这类格局。
更上一层楼：在目次树中怎样构造数据
在UNIX文件体系中，最顶层是根目次（root）。在根目次的上面有良多的文件和目次。象下面先容的那样，LDAP目次也是用一样的办法构造起来的。

在根目次下，要把数据从逻辑上辨别开。由于汗青上（X.500）的缘故原由，年夜多半LDAP目次用OU从逻辑上把数据分隔来。OU暗示“OrganizationUnit”，在X.500协定中是用来暗示公司外部的机构：发卖部、财政部，等等。如今LDAP还保存ou=如许的定名划定规矩，可是扩大了分类的局限，能够分类为：ou=people,ou=groups,ou=devices，等等。更低一级的OU偶然用来做更细的回类。比方：LDAP目次树（不包含独自的纪录）大概会是如许的：

dc=foobar,dc=com

ou=customers

ou=asia

ou=europe

ou=usa

ou=employees

ou=rooms

ou=groups

ou=assets-mgmt

ou=nisgroups

ou=recipes
独自的LDAP纪录DN是LDAP纪录项的名字
在LDAP目次中的一切纪录项都有一个独一的“DistinguishedName”，也就是DN。每个LDAP纪录项的DN是由两个部分构成的：绝对DN（RDN）和纪录在LDAP目次中的地位。

RDN是DN中与目次树的布局有关的部分。在LDAP目次中存储的纪录项都要有一个名字，这个名字一般存在cn（CommonName）这个属性里。由于几近一切的器材都有一个名字，在LDAP中存储的工具都用它们的cn值作为RDN的基本。假如我把最喜好的吃燕麦粥食谱存为一个纪录，我就会用cn=OatmealDeluxe作为纪录项的RDN。

l我的LDAP目次的基准DN是dc=foobar,dc=com

l我把本人的食谱作为LDAP的纪录项存在ou=recipes

l我的LDAP纪录项的RDN设为cn=OatmealDeluxe

下面这些组成了燕麦粥食谱的LDAP纪录的完全DN。记着，DN的读法和DNS主机名相似。上面就是完全的DN：

cn=OatmealDeluxe,ou=recipes,dc=foobar,dc=com
举一个实践的例子来讲明DN
如今为公司的员工设置一个DN。能够用基于cn或uid（UserID），作为典范的用户帐号。比方，FooBar的员工FranSmith（登录名：fsmith）的DN能够为上面两种格局：

uid=fsmith,ou=employees,dc=foobar,dc=com

（基于登录名）

LDAP（和X.500）用uid暗示“UserID”，不要把它和UNIX的uid号搅浑了。年夜多半公司城市给每个员工独一的登录名，因而用这个举措能够很好地保留员工的信息。你不必忧虑今后还会有一个叫FranSmith的到场公司，假如Fran改动了她的名字（娶亲？仳离？或宗教缘故原由？），也用不着改动LDAP纪录项的DN。

cn=FranSmith,ou=employees,dc=foobar,dc=com

（基于姓名）

能够看到这类格局利用了CommonName（CN）。能够把CommonName当做一团体的全名。这类格局有一个很分明的弱点就是：假如名字改动了，LDAP的纪录就要从一个DN转移到另外一个DN。可是，我们应当尽量地制止改动一个纪录项的DN。
定制目次的工具范例
你能够用LDAP存储各类范例的数据工具，只需这些工具能够用属性来暗示，上面这些是能够在LDAP中存储的一些信息：

l员工信息：员工的姓名、登录名、口令、员工号、他的司理的登录名，邮件服务器，等等。

l物品跟踪信息：盘算机名、IP地点、标签、型号、地点地位，等等。

l客户接洽列表：客户的公司名、次要接洽人的德律风、传真和电子邮件，等等。

l集会厅信息：集会厅的名字、地位、能够坐几人、德律风号码、是不是有投影机。

l食谱信息：菜的名字、配料、烹饪办法和筹办办法。

由于LDAP目次能够定制成存储任何文本或二进制数据，究竟存甚么要由你本人决意。LDAP目次用工具范例（objectclasses）的观点来界说运转哪一类的工具利用甚么属性。在几近一切的LDAP服务器中，你都要依据本人的必要扩大基础的LDAP目次的功效，创立新的工具范例大概扩大现存的工具范例。

LDAP目次以一系列“属性对”的情势来存储纪录项，每个纪录项包含属性范例和属性值（这与干系型数据库用行和列来存取数占有基本的分歧）。上面是我存在LDAP目次中的一部分食谱纪录：

dn:cn=OatmealDeluxe,ou=recipes,dc=foobar,dc=com

cn:InstantOatmealDeluxe

recipeCuisine:breakfast

recipeIngredient:1packetinstantoatmeal

recipeIngredient:1cupwater

recipeIngredient:1pinchsalt

recipeIngredient:1tspbrownsugar

recipeIngredient:1/4apple,anytype

请注重下面每种配料都作为属性recipeIngredient值。LDAP目次被计划成象下面那样为一个属性保留多个值的，而不是在每个属性的前面用逗号把一系列值分隔。

由于用如许的体例存储数据，以是数据库就有很年夜的天真性，不用为到场一些新的数据就从头创立表和索引。更主要的是，LDAP目次不用消费内存或硬盘空间处置“空”域，也就是说，实践上不利用可选择的域也不会消费你任何资本。
作为例子的一个独自的数据项
让我们看看上面这个例子。我们用Foobar,Inc.的员工FranSmith的LDAP纪录。这个纪录项的格局是LDIF，用来导进和导出LDAP目次的纪录项。

dn:uid=fsmith,ou=employees,dc=foobar,dc=com

objectclass:person

objectclass:organizationalPerson

objectclass:inetOrgPerson

objectclass:foobarPerson

uid:fsmith

givenname:Fran

sn:Smith

cn:FranSmith

cn:FrancesSmith

telephonenumber:510-555-1234

roomnumber:122G

o:Foobar,Inc.

mailRoutingAddress:fsmith@foobar.com

mailhost:mail.foobar.com

userpassword:{crypt}3x1231v76T89N

uidnumber:1234

gidnumber:1200

homedirectory:/home/fsmith

loginshell:/usr/local/bin/bash

属性的值在保留的时分是保存巨细写的，可是在默许情形下搜刮的时分是不辨别巨细写的。某些特别的属性（比方，password）在搜刮的时分必要辨别巨细写。

让我们一点一点地剖析下面的纪录项。

dn:uid=fsmith,ou=employees,dc=foobar,dc=com

这是Fran的LDAP纪录项的完全DN，包含在目次树中的完全路径。LDAP（和X.500）利用uid（UserID），不要把它和UNIX的uid号搅浑了。

objectclass:person

objectclass:organizationalPerson

objectclass:inetOrgPerson

objectclass:foobarPerson

能够为任何一个工具依据必要分派多个工具范例。person工具范例请求cn（commonname）和sn（surname）这两个域不克不及为空。persion工具范例同意有别的的可选域，包含givenname、telephonenumber，等等。organizationalPerson给person到场更多的可选域，inetOrgPerson又到场更多的可选域（包含电子邮件信息）。最初，foobarPerson是为Foobar定制的工具范例，到场了良多定制的属性。

uid:fsmith

givenname:Fran

sn:Smith

cn:FranSmith

cn:FrancesSmith

telephonenumber:510-555-1234

roomnumber:122G

o:Foobar,Inc.

之前说过了，uid暗示UserID。当看到uid的时分，就在脑壳里想想“login”。

请注重CN有多个值。就象下面先容的，LDAP同意某些属性有多个值。为何同意有多个值呢？假定你在用公司的LDAP服务器查找Fran的德律风号码。你大概只晓得她的名字叫Fran，可是对人力资本处的人来讲她的正式名字叫做Frances。由于保留了她的两个名字，以是用任何一个名字检索都能够找到Fran的德律风号码、电子邮件和办公房间号，等等。

mailRoutingAddress:fsmith@foobar.com

mailhost:mail.foobar.com

就象如今年夜多半的公司都上彀了，Foobar用Sendmail发送邮件和处置内部邮件路由信息。Foobar把一切用户的邮件信息都存在LDAP中。最新版本的Sendmail撑持这项功效。

Userpassword:{crypt}3x1231v76T89N

uidnumber:1234

gidnumber:1200

gecos:FrancesSmith

homedirectory:/home/fsmith

loginshell:/usr/local/bin/bash

注重，Foobar的体系办理员把一切用户的口令映照信息也都存在LDAP中。FoobarPerson范例的工具具有这类才能。再注重一下，用户口令是用UNIX的口令加密格局存储的。UNIX的uid在这里为uidnumber。提示你一下，关于怎样在LDAP中保留NIS信息，有完全的一份RFC。在今后的文章中我漫谈一谈NIS的集成。
LDAP复制
LDAP服务器可使用基于“推”大概“拉”的手艺，用复杂或基于平安证书的平安考证，复制一部分大概一切的数据。

比方，Foobar有一个“公用的”LDAP服务器，地点为ldap.foobar.com，端口为389。NetscapeCommunicator的电子邮件查询功效、UNIX的“ph”命令要用到这个服务器，用户也能够在任何中央查询这个服务器上的员工和客户接洽信息。公司的主LDAP服务器运转在不异的盘算机上，不外端标语是1389。

你大概即不想让员工查询资产办理或食谱的信息，又不想让信息手艺职员看到全部公司的LDAP目次。为懂得决这个成绩，Foobar有选择地把子目次树从主LDAP服务器复制到“公用”LDAP服务器上，不复制必要埋没的信息。为了坚持数据一直是最新的，主目次服务器被设置成立即“推”同步。这些种办法次要是为了便利，而不是平安，由于假如有权限的用户想查询一切的数据，能够用另外一个LDAP端口。

假定Foobar经由过程从奥克兰到欧洲的低带宽数据的毗连用LDAP办理客户接洽信息。能够创建从ldap.foobar.com:1389到munich-ldap.foobar.com:389的数据复制，象上面如许：

periodicpull:ou=asia,ou=customers,o=sendmail.com

periodicpull:ou=us,ou=customers,o=sendmail.com

immediatepush:ou=europe,ou=customers,o=sendmail.com

“拉”毗连每15分钟同步一次，在下面假定的情形下充足了。“推”毗连包管任何欧洲的接洽信息产生了变更就当即被“推”到Munich。

用下面的复制形式，用户为了会见数据必要毗连到哪一台服务器呢？在Munich的用户能够复杂地毗连到当地服务器。假如他们改动了数据，当地的LDAP服务器就会把这些变更传到主LDAP服务器。然后，主LDAP服务器把这些变更“推”回当地的“公用”LDAP服务器坚持数据的同步。这对当地的用户有很年夜的优点，由于一切的查询（年夜多半是读）都在当地的服务器长进行，速率十分快。当必要改动信息的时分，终极用户不必要从头设置客户真个软件，由于LDAP目次服务器为他们完成了一切的数据互换事情。
平安和会见把持
LDAP供应很庞大的分歧条理的会见把持大概ACI。因这些会见能够在服务器端把持，这比用客户真个软件包管数据的平安可平安多了。

用LDAP的ACI，能够完成：

l赐与用户改动他们本人的德律风号码和家庭地点的权限，可是限定他们对别的数据（如，职务称号，司理的登录名，等等）只要“只读”权限。

l赐与“HR-admins”组中的一切人权限以改动上面这些用户的信息：司理、事情称号、员工号、部门称号和部门号。可是对别的域没有写权限。

l克制任何人查询LDAP服务器上的用户口令，可是能够同意用户改动他或她本人的口令。

l赐与司理会见他们下级的家庭德律风的只读权限，可是克制其别人有这个权限。

l赐与“host-admins”组中的任何人创立、删除和编纂一切保留在LDAP服务器中的与盘算机主机有关的信息

l经由过程Web，同意“foobar-sales”组中的成员有选择地赐与或克制他们本人读取一部分客户接洽数据的读权限。这将同意他们把客户接洽信息下载到当地的条记本电脑或团体数字助理（PDA）上。（假如发卖职员的软件都撑持LDAP，这将十分有效）

l经由过程Web，同意组的一切者删除或增加他们具有的组的成员。比方：能够同意发卖司理赐与或克制发卖职员改动Web页的权限。也能够同意邮件化名（mailaliase）的一切者不经由IT手艺职员就间接从邮件化名中删除或增加用户。“公用”的邮件列表应当同意用户从邮件化名中增加或删除本人（可是只能是本人）。也能够对IP地点或主机名加以限定。比方，某些域只同意用户IP地点以192.168.200.*开首的有读的权限，大概用户反向查找DNS失掉的主机名必需为*.foobar.com。

这不外是让你懂得一下能够对LDAP目次举行如何的会见把持，实践上真正完成起来必要做的事情比这多很多。在今后的文章中我会具体地会商会见把持。
php本地模拟的prepare底层就是mysql_real_escape_string，所以必须得用mysql_set_character_set去设置mysql->charset，否则就存在字符集问题。

其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。

如果是将来做数据库的开发设计，就应该详细学习T-SQL的各种细节，包括T-SQL的程序设计、存储过程、触发器以及具体使用某个开发语言来访问数据库。

一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）

外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。

而SQLServer如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

可以动态传入参数，省却了动态SQL的拼写。

需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。

对于微软系列的东西除了一遍遍尝试还真没有太好的办法