鍍金池/ 問答/ 數(shù)據(jù)庫問答
北城荒 回答

@歐兜兜是素姀 的回答是正確的，mongoose的Schema可以使用required屬性來規(guī)范數(shù)據(jù)，這樣不符合要求的數(shù)據(jù)存入mongodb會失敗的。

但是，就算是數(shù)據(jù)庫規(guī)范了，前端也不能假設(shè)數(shù)據(jù)庫返回的數(shù)據(jù)沒問題，前端還是需要對后端返回的數(shù)據(jù)進(jìn)行驗證和容錯。因為前端和后端是分離的，前端需要假設(shè)后端會出錯。事實上，后端出錯也是無法避免的，因為代碼一直在修改，哪天后端不小心刪掉required字段呢？

嘟尛嘴 回答 
SELECT 
    parent_id, catalog_name INTO sParentId,sPathName 
FROM 
    t_knowledge_catalog 
WHERE 
    catalog_id = sChildId;

select 列名1,列名2...列名N into 參數(shù)1,參數(shù)2...參數(shù)N

憶往昔 回答 
$map = [];
if(!empty($price))
{
    $map['price'] = $price;
}
if(!empty($shoufu))
{
    $map['shoufu'] = $shoufu;
}
Db::table('xxxxx')->where($map)->select();
蝶戀花 回答

查出來之后，再進(jìn)行你的業(yè)務(wù)處理

乖乖噠 回答

不需要設(shè)置 conn.setAutoCommit(true);

conn.close();執(zhí)行后autoCommit屬性變?yōu)閠rue.
笨小蛋 回答
  1. 你的兩個截圖似乎執(zhí)行的并不是一個查詢（至少第二個截圖有sort，第一個Java代碼沒有）。
  2. 因為沒有說明這是什么圖形界面，執(zhí)行計劃也折疊起來看不見，所以無法判斷第二張截圖上的50是代表的意思是否影響到執(zhí)行計劃只取前50條結(jié)果。相比之下，Java那句代碼可是會把全部結(jié)果都取出來。這會造成很大的時間差異。

最后提點額外的建議與主題無關(guān)。能用文本粘貼的代碼、日志、執(zhí)行結(jié)果之類的東西，都用文本粘貼出來。圖片不僅看起來不方便，有時候截不全也對我們回答問題很不利。而且有時候我們需要使用你們的代碼、數(shù)據(jù)等來做測試，如果這時候只有截圖，基本上很多人當(dāng)場就會放棄了。

兮顏 回答

你好，請問rules里的validator可以和async-validator結(jié)合起來嗎？難道得一個的寫驗證器

夢一場 回答

npm init會初始化你的項目，就是里面什么都沒有，你需要重新下載項目
然后 npm install
再 npm start

Tag Aware Sharding可以達(dá)到你的目的，但是這樣到后期數(shù)據(jù)會不均衡，并不推薦這樣使用，還是盡可能讓它更均衡。

心沉 回答

node環(huán)境下用phantomjs是可以的。所有前端渲染的網(wǎng)站都適用。

以往的渲染頁面都是靜態(tài)的，給用戶看的都是加載好的，所以很容易爬，現(xiàn)在都是頁面動態(tài)渲染的，需要有一個模擬環(huán)境，執(zhí)行后再爬取

葬憶 回答

對于參數(shù)綁定為何可以避免SQL注入，建議題主可以了解一下，值得注意的是prepare語句只能解析一條SQL，下面摘要說明一下prepare的作用：
首先從mysql服務(wù)器執(zhí)行sql的過程開始講起，SQL執(zhí)行過程包括以下階段 詞法分析->語法分析->語義分析->執(zhí)行計劃優(yōu)化->執(zhí)行。詞法分析->語法分析這兩個階段我們稱之為硬解析。詞法分析識別sql中每個詞，語法分析解析SQL語句是否符合sql語法，并得到一棵語法樹（Lex）。對于只是參數(shù)不同，其他均相同的sql，它們執(zhí)行時間不同但硬解析的時間是相同的。而同一SQL隨著查詢數(shù)據(jù)的變化，多次查詢執(zhí)行時間可能不同，但硬解析的時間是不變的。對于sql執(zhí)行時間較短，sql硬解析的時間占總執(zhí)行時間的比率越高。而對于淘寶應(yīng)用的絕大多數(shù)事務(wù)型SQL，查詢都會走索引，執(zhí)行時間都比較短。因此淘寶應(yīng)用db sql硬解析占的比重較大。

Prepare的出現(xiàn)就是為了優(yōu)化硬解析的問題。Prepare在服務(wù)器端的執(zhí)行過程如下

1） Prepare 接收客戶端帶”?”的sql, 硬解析得到語法樹(stmt->Lex), 緩存在線程所在的preparestatement cache中。此cache是一個HASH MAP. Key為stmt->id. 然后返回客戶端stmt->id等信息。

2） Execute 接收客戶端stmt->id和參數(shù)等信息。注意這里客戶端不需要再發(fā)sql過來。服務(wù)器根據(jù)stmt->id在preparestatement cache中查找得到硬解析后的stmt, 并設(shè)置參數(shù)，就可以繼續(xù)后面的優(yōu)化和執(zhí)行了。

Prepare在execute階段可以節(jié)省硬解析的時間。如果sql只執(zhí)行一次，且以prepare的方式執(zhí)行，那么sql執(zhí)行需兩次與服務(wù)器交互（Prepare和execute）, 而以普通（非prepare）方式，只需要一次交互。這樣使用prepare帶來額外的網(wǎng)絡(luò)開銷，可能得不償失。我們再來看同一sql執(zhí)行多次的情況，比如以prepare方式執(zhí)行10次，那么只需要一次硬解析。這時候  額外的網(wǎng)絡(luò)開銷就顯得微乎其微了。因此prepare適用于頻繁執(zhí)行的SQL。

Prepare的另一個作用是防止sql注入，不過這個是在客戶端jdbc通過轉(zhuǎn)義實現(xiàn)的，跟服務(wù)器沒有關(guān)系。

建議題主看下MySQL官方文檔（https://dev.mysql.com/doc/ref...）。什么？看不懂英文？試試百度翻譯吧：https://fanyi.baidu.com

clipboard.png

朕略傻 回答

數(shù)據(jù)庫原生的話字符串是沒有單增這一說法的吧，你可以在應(yīng)用層做，比如：


SELECT CONCAT("KZ",id) as id from table1;
玩控 回答

設(shè)置連接池，其實這也是連接池的使用場景。
MongoClient 就有帶這個功能。
配置連接池的最大連接數(shù)就好了。

我以為 回答

desc是mysql的關(guān)鍵字, 從終端做為字段名時輸入時需要用反引號括起來使用

如:

SELECT * FROM your_table where `desc`='中文';

或者

SELECT * FROM your_table as t where t.desc='中文';

與字符集無關(guān).

參見:
https://dev.mysql.com/doc/ref...

款爺 回答

mongodump是個命令，你這里已經(jīng)進(jìn)去到mongo的命令行了，只能執(zhí)行mongo的語句，你應(yīng)該先退出mongo命令行，然后再執(zhí)行你的導(dǎo)出數(shù)據(jù)庫語句

小眼睛 回答

B聊天框的滾動軸自動滾動到最下方前先加一個判斷，判斷是否有上翻操作

有點壞 回答

我說下我們的做法，我們每天的交易數(shù)據(jù)量是200萬以上，核心在后半夜交易量極少的情況下做跑批清算，這個動作每天只做一次，在早上上班之前跑出結(jié)果，然后由清算人員進(jìn)行人工審核。數(shù)據(jù)庫用的是oracle10g，公司購買的正版。即使是埋點，從運(yùn)營角度出發(fā)，也是要寫入日志庫，然后再做二次分析。

有你在 回答

后來把配置的table_cache從512改到2000就可以了

首頁 上一頁 119 120 121 122 123 124 125 126 127 下一頁 尾頁