㈠ 金蝶K3可以在数据库把审核的单据删除或者反审核吗可以的话sql语句怎么写
不建议这么做，单据关联了的话，单删单据数据会有问题，你可以用sQL工具追踪下单据头跟体是哪个表的
㈡ 如何通过SQL语句设置数据库登录审核的状态
刚好上次讲三层架构.有现成的例子
以一个验证登陆为例子
这里是界面层一般叫UIL
protected void Button1_Click(object sender, EventArgs e)
{
List<User> Users = BAL.GetUserInfo(txtUserName.Text,txtPassword.Text);
if(Users.Length > 0)
{
Response.Write("登陆成功");
}
else
{
Response.Write("登陆失败");
}
}
以下是逻辑层代码,业务逻辑层一般叫BLL
public static List<User> GetUserInfo(string user,string password)
{
string newPassword = GetMD5Hash(password); //这里对密码进行加密处理,数据库中存放的是经过MD5加密后的密,业务逻辑层一般都是处理复杂的逻辑.例如加密逻辑
List<User> Users = DAL.GetUserInfo(user,newPassword);
return Users;
}
以下是数据访问层代码,数据访问层一般叫DAL
public static List<User> GetUserInfo(string user,string password)
{
List<User> Users = new List<User>();
string sql = "select * from User where Password = '"+password+"' and User = '"+user+"'"; //写where子句的时候把Password放前面.因为Password经过加密,所以可以防止SQL注入攻击
SqlDataAdapter da = new SqlDataAdapter(sql,"这里是数据库连接字符串");
DataSet ds = new DataSet();
da.Fill(ds);
for(int i=0;i<ds.Tables[0].Rows.Count;i++)
{
User user = new User(ds.Tables[0].Rows[i]["ID"].ToString(),ds.Tables[0].Rows[i]["User"].ToString(),ds.Tables[0].Rows[i]["Password"].ToString());
Users.Add(user);
}
return Users;
}
还会有一个Model层.叫做模板层.是数据表结构的印射.Model层是共用层,其他三层都要用到.
比如数据库中有张表User,里面有3个字段ID,User,Password
那么在模板层中应该有一个类,数据库中User表的一行对应一个User对象,一张表对应User对象的集合.
public class User
{
string ID;
string User;
string Password;
//重载构造函数
User(string id,string user,string password)
{
this.ID=id;
this.User=user;
this.Password=password;
}
}
㈢ 如何用sql语句查询单据是否审核
IFEXISTS(SELECTTOP11FROM表名WHERE审核字段='审核'AND单号='单号001')
SELECT'已审核'
ELSE
SELECT'未审核'
㈣ sql server 2008 状态字段 已审核未审核 怎么设置
启动SQL Server 2008 Management Studio“工具菜单—>选项”打开选项对话框
左侧目录树选择“设计器”取消勾选右侧“阻止保存要求重新创建表的更改”即可。
在其他版本的“设计器”项为英文“designers”
4
点击确定就设置好了，用CTRL+S就可以正常保存表结构的更改了。
㈤ 如何自动化完成SQL审核
很多游戏项目都是通过每周更新大版本来维持用户的粘性和活跃度，而更新版本必然伴随着数据库的新建create、改表alter的SQL。
运维或者dba负责审核这类sql是否合理、高效，因为很多开发同事特别是经验少的新人是不考虑sql性能、是否合乎MySQL的最佳实践。
经常很多建表语句漏加索引或者加错索引（不满足最左匹配等情况），需要等到开服后数据库负载过高引起告警才发现问题。
MySQL的配置中有一个日志是记录没有使用索引的sql，记录进slow log日志中，不过实际使用过程中，的确存在着很多合理的不使用索引的情况，所以这个日志一般不打开。
为了避免人工审阅的重复劳动，所以运维可以通过写程序、脚本来自动审核sql，而审核的条件一般如下：
1、表结构是否合法 //不合法当然不能通过
2、表名、列名长度超过 16 //主要跟我们自己的授权有关系
3、必须有 unsigned //业务最容易忘记添加，当然如果一定要负值，那么就走人工审核;
4、必须为 InnoDB //当然了，我已经忘记还有MyISAM了，统计日志表除外
5、int bigint(10) 不能小于 10 //大家见过int（1）的情况么？
6、varchar 长度小于 3000 // 这也算是一个人为规定，没有任何意义
7、text 字段个数不能大于 3 //人为规定而已
8、主键必须为 int 类型 //不int，真的会死人
9、索引不能有重复 //见过key（id）,key(id,uid)的情况吗？
10、索引个数不能大于 5 个（包括主键） //人为定义而已
11、索引字段必须为 not null，并且有 default 值 //参照高性能那本书说的，其实不一定影响性能
12、SQL 是否使用到索引 //不能用到索引的SQL，真的很惨
13、SQL 中不能有 * //由于* 经常导致流量、O巨大，所以，也强制了
14、自增字段必须为 int 或者 bigint //见过自增用smallint的吗？然后一下就溢出了
15、请不要使用MySQL的保留字(Reserved Words) //写脚本，大家讨厌<`>符号么？
开发提交sql后，会直接调用后端审核程序，程序根据以上规则，进行审核，就极大的降低了运维、DBA的工作量。
当sql审核通过后，是否马上执行？
根据以下情况判断：
1、表小于10w行，小于10M空间大小，那么直接执行SQL;
2、如果不满足1，并且满足percona online-schema-change条件，那么通过osc工具，进行在线修改;
3、如果1、2都不行，走人工上线流程;
㈥ SQL审核 | SQLE-SQL审核平台体验报告
通过SQLE的产品结构图我们可以看到，SQLE 的界面设计较简洁，工作台可以看到与自己相关的待办工作；首页列表放置核心功能【工单】审核，其它功能收集到平台管理中；【规则】可以考虑收入到【平台管理】中；【审核计划】也可以考虑收入到【平台管理】中，审核的结果可以集成到工单中，方便统一进行处理。
通过 SQLE 的流程图可以看到，整体流程分为两个两个部分，一个是基础配置，配置好了基础配置以后，就可以执行上线流程了；对于审核不合格的功能依旧可以执行工单，没有起到自动审核的意义，对于ERROR级别的错误可以自动驳回不与上线；进入工单页面后不能很好的发现审核操作按钮（工单进度部分），需要下拉窗口才能发现；可以把审核操作放到审核结果列表后面加一个操作列，体验会更加友好。下图为缩放67%后才能看到下面的审核操作.
（1）创建SQL工单-SQL语句不支持输入联想，建议增加输入联想，提高录入效率
（2）创建SQL工单-SQL语句对于明显语法错误不能及时提示，建议增加语法错误提示，提前发现明显问题
（3）创建SQL工单-SQL语句输入框高度过高，点击审核后不方便查看到结果，建议降低高度增加宽度
（4）创建SQL工单-工单不支持自定义上线时间，同时也不支持定时上线
由于时间有限，仅是个人测试体验；SQLE 整体设计不错，符合现在主流平台的各方面特征；主要几个设计点我比较喜欢：
㈦ SQL怎么取最新的一个季度数据
您好！这是我写的SQL。因为没有看到这个表的表名，所以我就用TEMPTABLE作为表名来写的，你在使用时直接将其替换为这个表的实际表名，再执行一下，看看是否能满足要求。
您好！因为这个平台可能有审查，我直接将SQL贴在这里无法发布。要么麻烦您私信联系我一下。我把SQL发给您。或者就是麻烦您按照上面的截图自己手动打出来验证一下。
㈧ 如何自动化完成SQL审核
sql审核主要完成两方面的目的.
1、避免性能太差的sql进入生产系统,导致整体性能降低
2、检查开发设计的索引是否合理,是否需要添加索引
第一点是SQL审核最核心的地方,避免乱七八糟的sql影响线上性能,甚至导致线上系统崩溃.
第二点是属于建模的范畴,要解决建模的最好办法是DBA参与项目前期审核,由DBA建模,如果DBA人力资源不足,那么就定期由DBA对开发人员进行培训.然后发现建模太烂的就扣KPI.
现在很多公司都是人肉来完成SQL审核的,人肉审核对dba的要求较高,需要懂一些代码,另外是费时费力,毕竟一般公司几十个开发,对应一个DBA，而且DBA还要干很多其他的事情.
如何将DBA从人肉SQL审核中解放出来呢?
思路其实很简单:
1、获取程序要执行的SQL
2、对要执行的SQL做分析,可以加各种分析条件来判断这个SQL是否可以自动审核通过,未通过审核的需要人工处理.
3、配合后期的慢查询日志分析系统完成长期的监控.
开源的解决方案主要有淘宝丹臣sqlautoreview系统.可以在github上搜索到.
但是这个系统主要是基于java sqlmapfile.xml解决自动创建索引的问题,对源数据有要求,并且是通过解析SQL结构来假设SQL的执行计划,不是特别准确,并且不能够很好的区分新sql还是老sql.
所以产生了一个新的方案:
1、为所有的执行过的sql产生一个figerprint
2、基于慢查询提供的数据,加上explain 提供的数据来判断这个sql的性能是否可接受,或者可优化.
3、自动审核通过性能可接受的部分,给DBA展示性能较差的sql,然后进行优化.
方案的优点在于:
基于用户真正执行的SQL,并且可以观察SQL执行频率.
基于MySQL真正的执行计划和执行结果,分析更准确.
每个SQL都有一个fingerprint,只需要增量处理新加的SQL,效率和性能提高.
基于Box anemometer二次开发,让慢查询和sql审核同平台,增加工具集成性,提高用户体验(DBA和开发人员)。
方案实施:
既然咱是DBA，肯定会有更DBA的思维方式.基于现有软件二次开发完成,减少开发成本,整合管理平台.
基于Box anemometer.安装Box anemometer
Box anemometer是一款B/S架构,图形化的MySQL慢查询分析工具.功能强大易用,设计简单直接.anemometer是基于pt-query-digest的二次封装得来.
核心处理流程:
mysql node–>计划任务通过pt-query-digest收集慢查询信息–>结果写入到数据库中–>anemometer按条件去展示慢查询的结果,并且提供了图形化和趋势分布图等功能.
所以anemometer已经帮我们完成了数据收集,包括每个sql的fingerprint信息,以及相关的信息,我们在测试环境,基于anemometer,将long_query_time设置为0,就可以收集到所以的SQL及相关信息.
在我们收集到所有SQL以后,我们就要来分析这个SQL是否可以自动审核通过.这里开始我们就要定制了.
定制内容如下:
一、
设置一个单独的datasources,可以命名为audit_sql.
这个datasources里面只放置开发环境或者测试环境的慢查询(你要做sql审核基于哪个环境),将此环境的long_query_time设置为0,接收所有的sql查询.
二、修改anemometer
ALTER TABLE `global_query_review` ADD audit_status VARCHAR(255) NOT
NULL DEFAULT ‘refuse’ comment ‘sql审计的状态 refuse未通过 pass审核通过’;
修改PHP代码.
在report模块的where条件中增加一个Ait Status的选项框,可以过滤audit_status的状态
在show_query模块中增加一个Audit Status的选项框,可以人工设置audit_status的状态
三、增加两个额外的脚本,准实时的分析audit_status为refuse的sql,如果sql的满足自动审核通过的条件,那么就设置audit_status为pass,表示自动审核通过.
自动审核未通过的sql,由DBA人工在anemometer上检索和处理.
这里就涉及到一个自动审核通过的算法:
算法分两种.
第一种是准实时,也就是可以几分钟或者一个小时运行一次,主要是根据每个sql的执行效率判断是否pass.
对应的脚本名字叫做:audit_sql.py
第二种是一天一次,弱化执行效率判断,增加一天执行的频率判断.
对应的脚本名字叫做:audit_sql_day.py
各家根据自己的实际情况调整或者优化这两个脚本.
至此,你已经可以让99%以上的代码自动审核通过了,审核不通过的代码你可以让开发自己来tracking也可以主动推给开发.
对于才搭建的环境,可能会有一些乱七八糟的sql,不过使用一段时间稳定以后,异常的sql指纹都有了,那么每天产生的sql指纹就比较少了,而这部分SQL指纹也就是程序员编写新的代码产生的.