MSSQL教程之一种复杂便利的权限办理办法--利用菜单...

MySQL是一个开放源码的小型关联式数据库管理系统，开发者为瑞典MySQLAB公司。目前MySQL被广泛地应用在Internet上的中小型网站中。菜单明天刚写完一个权限办理的程序，原本有良多办理计划能够完成，只是事先灵机一现，俄然想到用菜单来举行权限分派，由于年夜部分项目标权限要经由过程菜单来把持，关于在窗口中要把持的非菜单的控件，把持他们实在也能够用一个埋没的菜单来对应，如许有很多优点，最少能够在一上岸的时分就把一切权限用菜单的ENABLED为TRUE和FALSE来处置，今后，在必要判别权限时，取权限对应菜单的ENABLED一看便知，不必往数据库里取了！用菜单来举行权限分派的一年夜优点就是直不雅，所见即所得，经由过程点选菜单，使菜单项的CHECDED为TRUE即暗示具有该权限了。为FALSE即为不具有该权限。如许的体例，我以为编程对照复杂，比用TREEVIEW来的复杂，特别PB6。5的TREEVIEW还不带复选框，用TREEVIEW来分派权限也是不便利，用数据窗口情势，或则列表框都能够完成，不外我仍是自觉得用菜单来分派便利复杂，因而决意要如许做了！不敢独享，放在这里，也算是对以是匡助过我的网友申谢！
计划头脑：

条件：

权限是按菜单来分派的，一个菜单项对应是一个权限，窗口中要把持的非菜单控件经由过程隐性菜单项来表现到菜单上，包管一个菜单项对应一个权限。

1，从数据库内外取到用户组（脚色大概用户，都一样处置）所具有的权限

2依据这些权限设置菜单，将响应菜单项的CHECKED=TRUE（有权限）

3。用户在菜单长进行权限设置，要设有权限即设置响应菜单的CHECKED属性为真

反之，则假

4断定用户的选择，遍历菜单将每一个菜单项与用户组权限表对照，假如用户权限内外有的权限而在对应菜单里CHECKED=FALSE，则删往此权限，为TRUE则不处置，假如用户权限表中没有的权限而在对应菜单里CHECKED=TRUE，则增添此权限，为FALSE则不处置。

最终效果以下



：

在每一个菜单项的CLICKED事务里写

this.checked=notthis.checked




在做这个程序的时分，遇见一个最年夜的成绩就是，在点选菜单时，一点击左键菜单就不睁开了，要为下一个权限点选的时分，又要从头点开菜单，如许是很贫苦的。以是我想如果在点开菜单的同时，能够点选良多子项菜单，如许就能够只必要睁开一次菜单，然后能够给多个子菜单项举行权限设置了。

这但是个年夜成绩啊，问了良多高人。子界说可视类不克不及以菜单为基类。又不克不及给菜单界说用户事务来映照到WINDOW动静上。并且菜单只要CLICKED和SELECTED两个事务，菜单挪用CLICKED事务后会主动酿成不睁开形态，SELECTED事务里又不克不及用KEYDOWN函数来判别是不是点击了鼠标右键或着键盘按下了某个键，在这个事务里往触发窗口里自界说事务（这个事务里放了KEYDOWN来判别是不是有鼠标右键或其他键盘键按下），也不克不及遂愿。忧郁了我一天啊！

明天手写累了，先到这，如果人人以为放在这不会玷辱人人的眼睛的话，我会尽快勉力把下文写完的，

待续！




上面我们说了DML的闪回方案。但对于DDL却无能为力，对于大多数的DDL，即使是rowbase格式，二进制日志binlog中仍只记录语句本身。对于删表操作，只记录一个语句droptablet。仅凭这句话，无法还原表的数据。

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！

财务软件要用SQL也只是后台的数据库而已,软件都是成品的,当然多学东西肯定是有好处的..

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

入门没那么困难，精通没那么容易

可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。

你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。

这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？