当前位置:主页 > 游艇会手机版app正文

游艇会手机版app:浅谈数据库设计技巧(下)SQL教程

05月07日作者:黑曼巴


三、多用户及其权限治理的设计

开拓数据库治理类的软件,弗成能不斟酌多用户和用户权限设置的问题。只管今朝市道市面上的大年夜、中型的后台数据库系统软件都供给了多用户,以及细至某个数据库内某张表的权限设置的功能,我小我建议:一套成熟的数据库治理软件,照样应该自行设计用户治理这块功能,缘故原由有二:

1.那些大年夜、中型后台数据库系统软件所供给的多用户及其权限设置都是针对数据库的共有属性,并不必然能完全满意某些特例的需求;

2.不要过多的依附后台数据库系统软件的某些特殊功能,多种大年夜、中型后台数据库系统软件之间并不完全兼容。否则一旦日后必要转换数据库平台或后台数据库系统软件版本进级,之前的架构设计很可能无法重用。

下面看看若何自行设计一套对照机动的多用户治理模块,即该数据库治理软件的系统治理员可以自行添加新用户,改动已有用户的权限,删除已有用户。首先,阐发用户需求,列出该数据库治理软件所有必要实现的功能;然后,根据必然的联系对这些功能进行分类,即把某类用户需应用的功能归为一类;着末开始建表:

功能表(Function_table)

名称     类型    约束前提   阐明

f_idint 无重复  功能标识,主键

f_namechar(20)不容许为空功能名称,不容许重复

f_descchar(50)容许为空功能描述

用户组表(User_group)

名称     类型    约束前提   阐明

group_idint无重复用户组标识,主键

group_namechar(20)不容许为空用户组名称

group_powerchar(100)不容许为空用户组权限表,内容为功能表f_id的聚拢

用户表(User_table)

名称     类型    约束前提   阐明

user_idint无重复用户标识,主键

user_namechar(20)无重复用户名

user_pwdchar(20)不容许为空用户密码

user_typeint不容许为空所属用户组标识,和User_group.group_id关联

采纳这种用户组的架构设计,当必要添加新用户时,只需指定新用户所属的用户组;当今后系统必要添加新功能或对旧有功能权限进行改动时,只用操作功能表和用户组表的记录,原有用户的功能即可响应随之变更。当然,这种架构设计把数据库治理软件的功能鉴定移到了前台,使得前台开拓相对繁杂一些。然则,当用户数较大年夜(10人以上),或日后软件进级的概率较大年夜时,这个价值是值得的。

四、简洁的批量m:n设计

碰着m:n的关系,一样平常都是建立3个表,m一个,n一个,m:n一个。然则,m:n无意偶尔会碰到批量处置惩罚的环境,例如到藏书楼借书,一样平常都是容许用户同时借阅n本书,假如要求按批查询借阅记录,即列出某个用户某次借阅的所有册本,该若何设计呢?让我们建好必须的3个表先:

册本表(Book_table)

名称     类型    约束前提   阐明

book_idint无重复册本标识,主键

book_nochar(20)无重复册本编号

book_namechar(100)不容许为空册本名称

……

借阅用户表(Renter_table)

名称     类型    约束前提   阐明

renter_idint无重复用户标识,主键

renter_namechar(20)不容许为空用户姓名

……

借阅记录表(Rent_log)

名称     类型    约束前提   阐明

rent_idint无重复借阅记录标识,主键

r_idint不容许为空用户标识,和Renter_table.renter_id关联

b_idint不容许为空册本标识,和Book_table.book_id关联

rent_datedatetime不容许为空借阅光阴

……

为了实现按批查询借阅记录,我们可以再建游艇会手机版app一个表来保存批量借阅的信息,例如:

批量借阅表(Batch_rent)

名称     类型    约束前提   阐明

batch_idint无重复批量借阅标识,主键

batch_noint不容许为空批量借阅编号,同一批借阅的batch_no相同

rent_idint不容许为空借阅记录标识,和Rent_log.rent_id关联

batch_datedatetime不容许为空批量借阅光阴

这样的设计好吗?我们来看看为了列出某个用户某次借阅的所有册本,必要若何查询?首先检索批量借阅表(Batch_rent),把相符前提的的所有记录的rent_id字段的数据保存起来,再用这些数据作为查询前提带入到借阅记录表(Rent_log)中去查询。那么,有没有什么法子改进呢?下面给出一种游艇会手机版app简洁的批量设计规划,不需添加新表,只需改动一下借阅记录表(Rent_log)即可。改动后的记录表(Rent_log)如下:

借阅记录表(Rent_log)

名称     类型    约束前提   阐明

rent_idint无重复借阅记录标识,主键

r_idint不容许为空用户标识,和Renter_table.renter_id关联

b_idint不容许为空册本标识,和Book_table.book_id关联

batch_noint不容许为空批量借阅编号,同一批借阅的batch_no相同

rent_datedatetime不容许为空借阅光阴

……

此中,同一次借阅的batch_no和该批第一条入库的rent_id相同。举例:假设当前最大年夜rent_id是64,接着某用户一次借阅了3本书,则批量插入的3条借阅记录的batch_no都是65。之后别的一个用户租了一套碟,再插入出租记录的rent_id是68。采纳这种设计,查询批量借阅的信息时,只需应用一条标准T_SQL的嵌套查询即可。当然,这种设计不相符3NF,然则和上面标准的3NF设计比起来,哪一种更好呢?谜底就不用我说了吧。

五、冗余数据的取舍

上篇的“树型关系的数据表”中保留了一个冗余字段,这里的例子更进一步——添加了一个冗余表。先看看游艇会手机版app例子:我本来所在的公司为了办理员工的事情餐,和相近的一家小餐馆联系,天天用饭记账,用度按人数平摊,月尾由公司现金结算,每小我每个月的事情餐费从人为中扣除。当然,天天用饭的职员和人数都不是固定的,而且,因为每顿事情餐的所点的菜色不合,每顿的花费也不相同。例如,礼拜一中餐5人花费40元,晚餐2人花费20,礼拜二中餐6人花费36元,晚餐3人花费18元。为了方便谋略每小我每个月的事情餐费,我写了一个简陋的就餐记账治理法度榜样,数据库里有3个表:

员工表(Clerk_table)

名称     类型    约束前提   阐明

clerk_idint无重复员工标识,主键

clerk_namechar(10)不容许为空员工姓名

每餐总表(Eatdata1)

名称     类型    约束前提   阐明

totle_idint无重复每餐总表标识,主键

personschar(100)不容许为空就餐员工的员工标识聚拢

eat_datedatetime不容许为空就餐日期

eat_typechar(1)不容许为空就餐类型,用来区分中、晚餐

totle_pricemoney不容许为空每餐总花费

persons_numint不容许为空就餐人数

就餐计费细表(Eatdata2)

名称     类型    约束前提   阐明

idint无重复就餐计费细表标识,主键

t_idint不容许为空每餐总表标识,和Eatdata1.totle_id关联

c_idint不容许为空员工标识标识,和Clerk_table.clerk_id关联

pricemoney不容许为空每人每餐花费

此中,就餐计费细表(Eatdata2)的记录便是把每餐总表(Eatdata1)游艇会手机版app的一笔记录按就餐员工平摊拆开,是个不折不扣的冗余表。当然,也可以把每餐总表(Eatdata1)的部分字段合并到就餐计费细表(Eatdata2)中,这样每餐总表(Eatdata1)就成了冗余表,不过这样所设计出来的就餐计游艇会手机版app费细表重复数据更多,比拟来说照样上面的规划好些。然则,便是就餐计费细表(Eatdata2)这个冗余表,在做每月每人餐费统计的时刻,大年夜大年夜简化了编程的繁杂度,只用类似这么一条查询语句即可统计出每人每月的寄餐次数和餐费总帐:

SELECT clerk_name AS personname,COUNT(c_id) as eattimes,SUM(price) AS ptprice FROM Eatdata2 JOIN Clerk_tabsle ON (c_id=clerk_id) JOIN eatdata1 ON (totleid=tid) WHERE eat_date>=CONVERT(datetime,'"&the_date&"') AND eat_date

最近关注

热点内容

更多