ldap 测试表设计

1. ldap_oc_mappings    存储objeckClass 信息


表结构: 

Column


Desc.


id


objectClass的唯一标识


name


objectClass的名称


keytbl


对应的自定义表格名称


keycol


对应的自定义表格中关键字字段名称


create_proc


新增一个object时使用的SQL语句


delete_proc


删除一个object时使用的SQL语句


expect_return


执行新增或删除object的SQL语句,代表操作成果的SQL CODE值,通常是0。

实际数据:

id name keytbl keycol create_proc delete_proc expect_return
1 organization organization id
2 organizationalUnit org_unit id
3 inetOrgPerson users id

2.    ldap_attr_mappings   存储 ldap中属性attribute 和objectclass 的连接关系

    表结构:

Column


Desc.


id


attribute唯一标识


oc_map_id


所属objectClass的唯一标识


name


Attribute名称


sel_expr


SELECT后面的SQL语句


sel_expr_u


from_tbls


FROM后面的SQL语句


join_where


WHERE后面的SQL语句


add_proc


修改一个attribute值时使用的SQL语句


delete_proc


删除一个attribute值时使用的SQL语句


param_order


官网给出的例子中,这个字段的值全是3


expect_return


执行修改或删除attribute值的SQL语句,代表操作成果的SQL CODE值,通常是0。

实际数据:

id oc_map_id name sel_expr sel_expr_u from_tbls join_where add_proc delete_proc param_order expect_return
1 1 dc name organization 3
2 2 ou name org_unit 3
3 3 uid uid users 3
4 3 sn name_en users 3
5 3 cn name_cn users 3
6 3 userPassword password users 3
7 3 mail email users 3

3.  ldap_entries 存储所有entry信息

表结构:

Column


Desc.


id


entry唯一标识


dn


entry的dn


oc_map_id


所属objectClass的唯一标识


parent


父节点entry的唯一标识


keyval


对应的自定义表格中,该对象的唯一标识。

实际数据

id dn oc_map_id parent keyval
1 dc=xywy,dc=com 3 1
2 ou=users,dc=xywy,dc=com 1 1 1
3 uid=admin,ou=users,dc=xywy,dc=com 2 2 1
4 uid=fuzengjie,ou=users,dc=xywy,dc=com 2 2 2

4   organization 存储Basc DN 即 目录树的根

表结构

Column


Desc.


id


目录树的ID


name


目录树的name

实际数据:

id name
1 xywy

5.org_unit 存储OU 组织单元

表结构:

Column


Desc.


id


OU的ID


name


OU的name

实际数据:

id name
1 users

6.users   存储 OU users的具体 信息

表结构:

Column desc:
id 用户IP
name_en 用户中文名
name_cn 用户英文名
password 用户密码
email 用户邮箱
code code值

实际数据:

id name_en name_cn password email code
1 admin admin 1234 [email protected] 1
2 fuzengjie fuzj 1234 [email protected] 34

来自为知笔记(Wiz)

原文地址:https://www.cnblogs.com/pycode/p/9495805.html

时间: 2024-08-15 09:44:33

ldap 测试表设计的相关文章

mysql中的索引原理与表设计

索引是有效使用数据库的基础,但你的数据量很小的时候,或许通过扫描整表来存取数据的性能还能接受,但当数据量极大时,当访问量极大时,就一定需要通过索引的辅助才能有效地存取数据.一般索引建立的好坏是性能好坏的成功关键. 1.InnoDb数据与索引存储细节 使用InnoDb作为数据引擎的Mysql和有聚集索引的SqlServer的数据存储结构有点类似,虽然在物理层面,他们都存储在Page上,但在逻辑上面,我们可以把数据分为三块:数据区域,索引区域,主键区域,他们通过主键的值作为关联,配合工作.默认配置下

班级通讯录系统初步设计--表设计

知识概要: 数据表设计初步 重构登陆界面和主界面设计初步 教学设计: 一.  通讯录系统开发维护Ver0.1 1.开始维护现有程序,理解程序,用例图Ver1.0. 2.找bug,改bug,重构小部分代码,以满足用户的需求.在现有版本的基础上做增量开发 1)         理解需求 2)         设计 3)         开发 4)         测试 二.  "班级通讯录管理系统"数据库和数据表样本设计初步 1.数据库初步应用 2.纸质的班级通讯录----"联系

走向DBA[MSSQL篇] 针对大表 设计高效的存储过程【原理篇】 附最差性能sql语句进化过程客串

原文:走向DBA[MSSQL篇] 针对大表 设计高效的存储过程[原理篇] 附最差性能sql语句进化过程客串 测试的结果在此处 本篇详解一下原理 设计背景 由于历史原因,线上库环境数据量及其庞大,很多千万级以上甚至过亿的表.目标是让N张互相关联的表 按照一张源表为基表,数据搬移归档 这里我们举例N为50 每张表数据5000W 最差性能sql进化客串 2表KeyName 字段意义 名称等相同 从bug01 表中取出前500条不在bug02 表中的数据 最差性能: SELECT TOP 500 a.K

【数据库】Mysql中主键的几种表设计组合的实际应用效果

写在前面 前前后后忙忙碌碌,度过了新工作的三个月.博客许久未新,似乎对忙碌没有一点点防备.总结下来三个月不断的磨砺自己,努力从独乐乐转变到众乐乐,体会到不一样的是,连办公室的新玩意都能引起莫名的兴趣了,作为一只忙碌的 “猿” 倒不知正常与否. 咳咳, 正题, 今天要写一篇关于mysql的主键.索引的文章,mysql的研究博主进行还不够深入,今天讨论的主题主要是,主键对增删改查的具体影响是什么? 博主将用具体的实验说明. 如果你不了解主键,你可以先看看下面的小节,否则你可以直接跳转到实验步骤 了解

非常好用的一个表设计工具(EZDML)

表结构设计器(EZDML) 官网:http://www.ezdml.com/ 这是一个数据库建表的小软件,可快速的进行数据库表结构设计,建立数据模型.类似大家常用的数据库建模工具如PowerDesigner.ERWIN.ER-Studio和Rational-Rose等的超级精简版. 包含功能:1. 表结构设计:创建表.字段.主键.外键.索引和注释:2. 表描述:可直接编辑文字描述快速生成表结构,爱用键盘的人会喜欢这个功能:3. 模型图:自动生成模型图:可设计和显示物理/逻辑视图,支持自动布局.平

MySQL的多表设计

一.外键约束 保证数据的完整性. 定义外键约束: 可以直接在create语句中定义外键 foreign key 当前表名(字段名) references 目标表名(目标表的主键) 创建完语句后,可以直接使用修改语句定义 alter table 表名 add foreign key 当前表名 (字段名) references 目标表名(目标表的主键) 二.多表设计的三种实体关系 多对多.一对多和一对一 三.多表设计之---------一对多 一个班级可以有多个学生,但是一个学生只能属于一个班级.或

php不用递归完成无限分类,从表设计入手完整演示过程

无限分类是什么就不废话了,可以用递归实现,但是递归从数据库取东西用递归效率偏低,如果从表设计入手,就很容易做到网站导航的实现,下面是某论坛导航,如下图 网上无限分类大多不全面,今天我会从设计表开始, 首先我们先做视图界面, <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>白超华-博客园</title> &

ERP开发分享 1 数据库表设计

这是我的ERP设计经验分享系列,今天讲的是数据库的表设计(1),主要阐述: 1.单字段的主键:2.使用int32作为主键类型:3.使用版本字段处理乐观锁定:4.生效字段标明是否允许“被使用”:5.锁定字段处理悲观锁定:6.行唯一字段处理分布式应用:

日志表设计一例分析

关于关系表的设计归根结底有两个方面.第一,就是完全按照范式理论去设计,一般来说达到第三范式就可以了,或者你可以划分的更细到达更上一层次.比如第四,第五,第六等等.这种设计有自己的可读性很强,但是有一点,在检索数据的时候增加了多张关系表来做关联的开销.第二,就是在范式理论上适当的做些反范式,有的东西还是不要太剥离的好.(窄表以及宽表) 这点和软件设计中的紧耦合松耦合理论一致. 下面我就以常用的LOG表来做下演示,其中有两种表的实际,一种是窄表,一种是稍微宽一点的表.窄表:log_ytt mysql