㈠ 金蝶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指紋也就是程序員編寫新的代碼產生的.