鍍金池/ 問答/ 數(shù)據(jù)庫問答
鹿惑 回答

檢查一下MIDDLEWARE_CLASSES里是否開啟了django.contrib.auth.middleware.AuthenticationMiddleware

另外最好的調(diào)試方法是斷點(diǎn)一步步看看是什么原因

孤星 回答

======================作者的解答=================================
在步驟installation的時(shí)候先執(zhí)行exector.
然后再product configuration 就不會(huì)爆上訴錯(cuò)誤提示了

小眼睛 回答

使用MongoDB的第一件事情就是忘掉關(guān)系模型，充分利用反范式、冗余來達(dá)成最高的讀寫效率。你已經(jīng)發(fā)現(xiàn)了現(xiàn)在的數(shù)據(jù)模型不好用，為什么不換個(gè)思路來解決問題？
決定數(shù)據(jù)模型的是你需要怎么使用這些數(shù)據(jù)。在不知道你打算怎么用這些數(shù)據(jù)的前提下，以下是一些按照常理的推測。
現(xiàn)在涉及的實(shí)體有3個(gè)：

  • teacher
  • student
  • class

其中:

  • teacher:class = 1:n
  • class:student = 1:n

對于1:n的情況，最常見的做法是把1冗余到n。比如學(xué)生可以是：

{
    _id:ObjectId(123456789...),
    name:'zhangsan',
    age:20,
    class: {
        classId: ObjectId(123456789...),
        number:10,
        // 其他常用字段
    }
}

當(dāng)然你也可以不要class的詳細(xì)信息，畢竟一個(gè)班的學(xué)生只用查一次班級信息。

{
    _id:ObjectId(123456789...),
    name:'zhangsan',
    age:20,
    classId: ObjectId(123456789...)
}

用的時(shí)候是不是會(huì)方便一些？
沒錯(cuò)，冗余有可能會(huì)造成數(shù)據(jù)不一致，但是你真的會(huì)這么在乎一致性嗎？通常的回答是不會(huì)。
比如如果班級信息如果要修改怎么辦？那就會(huì)造成每個(gè)學(xué)生的班級信息都更新一遍，修改時(shí)壓力會(huì)比較大操作比較復(fù)雜。但是別忘了你的系統(tǒng)大部分壓力是來自讀而不是寫。班級修改的概率有多大？可能幾個(gè)月不見得有一次。但是讀班級的概率有多大？可能每天就有好多次。比較一下孰輕孰重不言而喻。

綜上，使用MongoDB時(shí)不要用范式來約束自己，從性能，易用性來考慮就可以了。

綰青絲 回答

//新聞?lì)愋颓袚Q
if(isset($_GET['newstype']) && !empty($_GET['newstype'])){

}

涼汐 回答

咳咳，老朋友來了。

1.首先是存儲(chǔ)的問題，存儲(chǔ)數(shù)組可以使用字符串的一個(gè)字段來存，將數(shù)組 JSON.stringify()序列化之后存成字符串。
2.建議使用Sequelize這個(gè)orm庫，一是封裝很多很方便的sql操作，也可以用原生sql，二是避免sql注入。
3.express響應(yīng)json直接用res.json(obj)。
4.上述代碼的query的if err那里建議加上return，因?yàn)闆]有用else，會(huì)導(dǎo)致響應(yīng)兩遍而報(bào)錯(cuò) Can't set headers after they are sent

emmmm

壞脾滊 回答

你是不是在創(chuàng)建表的時(shí)候 是創(chuàng)建的內(nèi)存式臨時(shí)表，臨時(shí)表在斷開連接后自動(dòng)清空表數(shù)據(jù)的。

久舊酒 回答

executeBatch()
executeBath()
?

不能再捕獲異常的位置，把執(zhí)行sql全部都打印出來，然后，去數(shù)據(jù)庫客戶端，手動(dòng)嘗試一次嗎？

夏夕 回答

為啥要在sql里面做這么多的邏輯處理，查出結(jié)果再對數(shù)據(jù)處理的方式比較好吧，也不必依靠id和日期的對應(yīng)關(guān)系

夢若殤 回答

是不是不能用雙引號呀，你用單引號試試。

我用 sql server 測試沒問題。

clipboard.png

夢一場 回答

改變?nèi)萜鞔笮　eries[{center:['30%','50%']}];center里面的參數(shù)調(diào)節(jié)圖的位置。

心上人 回答

借花獻(xiàn)佛
https://blog.csdn.net/u010003...
另外MongoDB 4.0已經(jīng)開始支持事務(wù)了

網(wǎng)妓 回答

有圖形化界面的版本，推薦你使用，方便調(diào)試。

陌顏 回答

mongo很適合做這樣的事情， 文章下面套一個(gè)評論的結(jié)構(gòu)。

大致結(jié)構(gòu)：

{
    title: String,
    content: String,
    createTime: DateTime,
    comments: [
        userName: String,
        //可以考慮，這里只存放第一層嵌套。 嵌套里的評論以JSON字符串的形式存在(假設(shè)讀比寫多，這樣做查詢效率高。）
        content: String 
    ] 
}

不過具體還是要看需求。

  1. 評論是否作為單獨(dú)的概念出現(xiàn)。 如一些針對評論的統(tǒng)計(jì)。
  2. 評論的是否無限級嵌套。
  3. 評論是否頻繁需要修改，如點(diǎn)贊。
陪妳哭 回答

你要看下你的自增序列是來自哪里，正常情況如果你刪除數(shù)據(jù)庫重建之后，自增偏移量是會(huì)重置的
有這么幾種可能：
1、有這么一個(gè)全局序列表用來存儲(chǔ)你的自增id值，重建db并沒有初始化該序列表
2、你是不是使用的刪除前的sql進(jìn)行的重建，建表sql是會(huì)附帶當(dāng)前自增值的，你需要重置掉這個(gè)auto_increment
最后一個(gè)，你的每次遞增3的情況，要么是全局配置id配置好的，要么就是你的集群節(jié)點(diǎn)自己配置自增的，自己去看配置就對了

夢囈 回答

已經(jīng)解決了，加一個(gè)條件即可
update A set a = (select b from B where B.id = A.id) where A.id in (select B.id from B)

安若晴 回答

shift使用錯(cuò)了

if(a[0]==='-1'){
    // a.shift()表示數(shù)組a移除第一個(gè)值,并返回該值   
    this.game_app_key=a.shift();    // 這里this.game_app_key就變成了-1
   }

正確的方法應(yīng)該是

if(a[0]==='-1'){
    a.shift()
    this.game_app_key=a;    // 這里this.game_app_key就變成了剩下的值
   }
黑與白 回答

數(shù)據(jù)庫中，為了加快數(shù)據(jù)的查找我們通常會(huì)加一個(gè)索引，如果你在mysql的selecte 語句中加了函數(shù)的話，那么這個(gè)索引就失效了，所以我們可以使用虛擬列，這個(gè)虛擬列會(huì)專門存放運(yùn)行函數(shù)后的結(jié)果，

http://www.techug.com/post/my...

首頁 上一頁 25 26 27 28 29 30 31 32 33 下一頁 尾頁