在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

主要看具體業(yè)務(wù)需求，不過更推薦方案一。

首先，字段的冗余并不是一個多大的缺點，另外，用事務(wù)來實現(xiàn)多表操作也很方便。

而方案一帶來的好處除了查詢效率高，最關(guān)鍵的是支持的業(yè)務(wù)場景更多，雖然現(xiàn)在看，收藏數(shù)好像也不是個重要字段，但是某天產(chǎn)品突然加需求說，咱們要按收藏數(shù)來個排序，分頁等各種，這時候用方案二實現(xiàn)起來就會越來越惡心

很有可能是你這幾條數(shù)據(jù)已經(jīng)被刪除了

但是沒有刷新數(shù)據(jù)庫

導(dǎo)致拋出刪除已經(jīng)不存在的數(shù)據(jù)

刷新一下試試

1.你點擊時跳轉(zhuǎn)時傳入的參數(shù)是否有問題？
2.建議你可以把這部分代碼貼出來，這樣大家也能更好幫你定位問題所在！

963,1040,1008,1016,992,1010,997,1000,1025,998,971,1036,962,998,972,954,1040,931,953,1018,1054,992,934,983,1027,973,1021,1044,997,1010,1062,978,988,1028,972,986,979,922,1032,924,993,1055,1054,1031,1023,981,1027,1017,1005,1031,1004,1009,994,1004,967,1026,1016,984,1032,987,1053,964,978,983,985,992,948,1061,1068,993,933,1028,967,1010,1007,962,1018,978,1003,1036,1001,1021,1006,1006,1041,1022,971,957,956,1007,1023,952,1011,988,991,984,1020,1025,1003,1018

這個10000個數(shù)分100個表，平均每個表數(shù)的總個數(shù)，分布的很均勻了好吧。
然后用哈希速度快，也很裝逼有木有^_^

在 sql 下, 方案2更好. 在 mongo 下, 方案1更好.
不知道你的這個項目中有沒有用戶權(quán)限組的概念.
如果有權(quán)限組的話, 就是一個權(quán)限組的 collection 里面, 每個權(quán)限下保存了一個菜單項的數(shù)組.
如果沒有權(quán)限組的話, 就可以按照你說的方案1, 在每個用戶表里, 或者單獨的用戶權(quán)限表里, 保存一個菜單數(shù)組.
當然, 保存菜單項的 id 數(shù)組或許更合適.

mongo 里面數(shù)組也是可以建立索引的, 查詢也很方便.
另外, 也可以參考 mongo 自身的權(quán)限系統(tǒng), 其權(quán)限設(shè)置也是保存在 mongo 數(shù)據(jù)庫內(nèi)的, 通常都是 admin 庫下的 users 表. 如果你的 mongo 開啟了權(quán)限管理, 并且權(quán)限庫名字就叫 admin, 則可以用以下命令查看:

> use admin
switched to db admin
> show users
{
    "_id" : "admin.admin",
    "user" : "admin",
    "db" : "admin",
    "roles" : [
        {
            "role" : "root",
            "db" : "admin"
        }
    ]
}
{
    "_id" : "admin.migration",
    "user" : "migration",
    "db" : "admin",
    "roles" : [
        {
            "role" : "backup",
            "db" : "admin"
        },
        {
            "role" : "read",
            "db" : "local"
        },
        {
            "role" : "read",
            "db" : "some_database"
        }
    ]
}
{
    "_id" : "admin.sys",
    "user" : "sys",
    "db" : "admin",
    "roles" : [
        {
            "role" : "__system",
            "db" : "admin"
        }
    ]
}

以上輸出為示例. 可以看到官方存儲權(quán)限的方案也是用數(shù)組.

參考:
mongo 官方文檔 - 用戶權(quán)限管理
mongo 官方文檔 - 數(shù)組索引

css: 'style!css!autoprefixer'改成css: 'style-loader!css-loader!autoprefixer-loader'這種寫法試試？

我沒有看過直播，但是這個例子我想應(yīng)該是這樣理解：
最初的代碼里面，很多硬編碼，主要時那兩段if-else，如果要加入其他按鍵，比如c鍵、d鍵，會很麻煩
重構(gòu)之后g.keydowns保存所有預(yù)定義的按鍵的狀態(tài)，g.actions里面保存按鍵上綁定的函數(shù)，然后在下面的setInterval中接收按鍵的狀態(tài)，然后調(diào)用綁定的函數(shù)，這樣一來，以后要加入新的按鍵和函數(shù)就會很容易，只要對外開放一個注冊接口，然后在外面注冊就行了。
這是一個比較經(jīng)典的重構(gòu)的例子，martin fowler的書里面講過

你給出的示例數(shù)據(jù)不對吧？ 第一個數(shù)組 qty都是2,第二個數(shù)組里面qty都是1，怎么能有相等的？

參考實現(xiàn)：

$arr1 = [
    ['qty' => '2', 'country' => 'ID', 'sku' => 'B00208MM01000', 'id' => '50040019'],
    ['qty' => '2', 'country' => 'ID', 'sku' => 'B00208MM03000', 'id' => '50040019']    
];
$arr2 = [
    ['qty' => '1', 'country' => 'ID', 'sku' => 'B00208MM01000', 'id' => '1040'],
    ['qty' => '1', 'country' => 'ID', 'sku' => 'B00208MM02000', 'id' => '1041'],
    ['qty' => '1', 'country' => 'ID', 'sku' => 'B00208MM03000', 'id' => '1042'],
    ['qty' => '1', 'country' => 'ID', 'sku' => 'B00208MM01000', 'id' => '1043'],
    ['qty' => '1', 'country' => 'ID', 'sku' => 'B00208MM02000', 'id' => '1044']
];

$finalArr = [];
foreach ($arr1 as $k => $v) {
    foreach ($arr2 as $k2 => $v2) {
        if ($v2['qty'] == $v['qty'] && $v2['country'] == $v['country'] && $v2['sku'] == $v['sku']) {
            array_push($finalArr, $v2);
        }
    }
}
print_r($finalArr);

1. 列表和詳情是兩張表，用id關(guān)聯(lián)。
2. 詳情可放在數(shù)據(jù)庫內(nèi)，也可不放在數(shù)據(jù)庫內(nèi)，實現(xiàn)方式有很多，重點看文章內(nèi)容及大小。
3. 先獲取列表，然后根據(jù)列表內(nèi)單個項的id去獲取詳情。

找到了一個解決方法， 設(shè)置id_card為unique index, 這樣如果有重復(fù)的id_card數(shù)據(jù)插入或者修改就會拋sql異常~~~ 完美解決了這個問題

異步請求到的值在 Management created 之后拿到, 所以才會表現(xiàn)為你說的那樣 console 輸出 0

恭喜你，寫法是正確的，不用懷疑。
你這種直接操作庫的業(yè)務(wù)沒有必要自定義異常，數(shù)據(jù)庫執(zhí)行錯誤或異常會自己拋異常的。

1.首先如果是web請求 則可以簡單開啟php-fpm的慢查詢?nèi)罩?。分析出那些請求耗時過長。。此方法可以初略的查到問題所在

1. 具體問題分析。如果不依賴其他工具。則可以在一段代碼的開始 記錄一個時間值最好用微秒。在覺得可能耗時的代碼后面用當前微秒時間-之前記錄的微秒時間。。這其實有點類似于hooks.

3.依賴第三方工具。或者php自帶的拓展。太多。。自行翻閱官方文檔。

https://docs.mongodb.com/manu...
最后發(fā)現(xiàn)php操作mongodb其實就是對mongodb操作的一種映射,可以直接去看mongodb的官方文檔,然后按照規(guī)則傳參

這種情況很少見了，但是驗證的方法很簡單。
你去把自己寫的sql拿出來，然后把沒有插入成功那條記錄帶入，不通過代碼，執(zhí)行一次sql。（其實就是手動插入一條記錄，看這兩個字段是否有值）
如果有值，那么很可能是你的sql跟實體類屬性或者跟數(shù)據(jù)庫字段哪個地方?jīng)]有對應(yīng)好。

For example, I want to use a loop: when a user enters a name ( skyped, clicker heroes games,..jany..) , he or she will export the corresponding hotmail ( clickerheroes@hotmail.com)

評論和回答應(yīng)該是分表的。
評論表應(yīng)該會有這些字段：
id 自增
content 評論的內(nèi)容
uid 誰寫的評論
type 類型，是問題的評論，還是回答的評論
qid/answer_id 問題或回答的id,當然，也可以把問題評論和回答的評論分成不同的表，這樣，type字段就可以不要了。
time 添加時間
zan 獲得的點贊數(shù)
pid 回復(fù)的對象，如果沒有則為0
status 狀態(tài)，正常，還是被刪除，或者是用戶自己刪除（刪除方式，segmentfault 不一定有區(qū)分)

相關(guān)聯(lián)的表應(yīng)該有：
用戶表，與uid關(guān)聯(lián)
問題表，與qid關(guān)聯(lián)
回答表，與answer_id關(guān)聯(lián)（與qid二選一)
贊同表，每一個贊同應(yīng)該都是有紀錄的，所有應(yīng)該有個獨立的表，但它們之間的關(guān)系一般是“同時”，與上面幾個的“關(guān)聯(lián)”不太一樣。

是我的話，差不多會這樣設(shè)計。

inner join本來走一個關(guān)聯(lián)字段的索引就夠了
你非要讓人家回表再篩選一遍當然慢了
要優(yōu)化就結(jié)合業(yè)務(wù)，
1、子查詢里面索引選擇是不是最優(yōu)了，比如user_id是不是會比create_time更快？
2、1表2表使用了out_trade_no關(guān)聯(lián)，看字段名應(yīng)該是交易單號一類的，這種是否還需要在2表進行時間篩選？
3、最后一個排序加limit是最耗時的，內(nèi)存排序再過濾掉幾萬數(shù)據(jù)明顯不合理，嘗試其他方式篩選，比如時間劃分粒度更小一點，翻頁功能實現(xiàn)網(wǎng)上方案很多，多看下，借鑒一下別人的實現(xiàn)方式

我有一個想法，不知道是否可行。exchange的結(jié)構(gòu)不改動，新建一張表

CREATE TABLE `exchange_statistics` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `volume_statistics` text NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

其中volume_statistics字段記錄的是通過數(shù)組序列化或者符號分割后的最新的144個值，144個值可以是從小到大或者按時間整理好，然后每隔5分鐘最前的元素剔除，從后面加入最新的元素。

這樣每個交易所預(yù)處理好最新的144個值，獲取交易所列表直接查詢exchange_statistics即可。

exchange結(jié)構(gòu)不需要改動，防止以后業(yè)務(wù)改動，有涉及統(tǒng)計的功能。

這種方案不知如何？

id是主鍵，單查id會用到主鍵唯一索引，而且查1列跟查多列的速度肯定是不一樣的