數據抓取/重組速度

這個問題可能會被標記爲過寬或意見爲主，但我冒這個險......數據抓取/重組速度

我有一個PHP REST的API，它從一個MySQL表獲取的所有數據，還包括'hasMany'字段。我們稱他們爲'post'hasMany'comments'。

現在我做一選擇與LEFT JOIN的意見，然後再通過結果走到輸出重組到

{ "posts": [ 
    {"id": 1, 
    "comments": [1,2,3] 
    }, 
    .... 
]}

一切都很好，直到我有一個以上的hasMany場，因爲那麼重構變得複雜（現在產生了雙重條目），我需要多次遍歷結果（不是手動的，但仍然使用內置函數）。

於是我想到了我的refacturing代碼：
1.選擇實際的項目（ '後'）
2.選擇所有的hasMany字段（ '意見'， 'anythingelse'，...）並添加結果。
這當然會在我的db上產生大量的動作。

所以我的問題是如果有人有一個簡單的答案，如'更好地抓住數據庫中的所有數據，並在php中完成工作'或相反。

是的，我可以自己做基準測試。但拳頭 - 說實話，我想避免所有重新編程只是爲了找出它的速度慢 - 第二我不知道我的基準測試是否會保持在優化（和Linux）生產機器上相同（現在我正在開發在windows上easyPhp）。

某些信息：「發佈」表可能會產生幾百條記錄，與hasMany相同。但結合一些hasMany領域，它可能會導致數千個記錄集（第一個問題）。

來源

2016-04-20 Jeff

使用IN (…)運算符。

首先，讓自己的相關帖子：

SELECT […stuff…] FROM posts WHERE […conditions…]

再從結果你到達那裏後ID列表並替換整個列表爲一組的形式的查詢：

SELECT […stuff…] FROM comments WHERE post_id IN (1, 2, 3 […etc…]) 
SELECT […stuff…] FROM anythingelse WHERE post_id IN (1, 2, 3 […etc…])

對每個從屬表運行一個查詢很好。這並不比運行單個JOINed查詢更昂貴;事實上，它可能更便宜，因爲父表中沒有重複的字段。

當然，確保post_id列在子表上被索引。

來源

2016-04-20 21:54:18 duskwuff

謝謝你，你的_edit_是我最重要的部分！ – Jeff

，我能想到的最好的替代辦法是沿着線：

$posts = $dbh->prepare('SELECT [fields] FROM posts WHERE [conditions]')-> 
    execute([...])-> 
    fetchAll(); 

$stmt = $dbh->prepare('SELECT id FROM comments WHERE post_id = ?'); 
for($i=0; $i<count($posts); $i++) { 
    $stmt->execute($posts[$i]['id']); 
    $posts[$i]['comments'] = $stmt->fetchAll(); 
}

你需要決定是否處理的工作/開銷權衡「重複」數據的加入是一個結果多於或少於單獨檢索每個帖子的評論。

如果你使用的是ORM，那麼很可能會發生自動化。

來源

2016-04-20 21:47:50 Sammitch

'你需要決定'是真正的問題...謝謝！ – Jeff

所有這些都取決於應用程序的性質，數據和系統體系結構。除了你以外，沒有人能夠衡量你的特定環境。 – Sammitch

是的，我知道這個問題非常廣泛。你們倆都給了我同樣的道路，我會在我的環境中做基準測試。我只是需要一個想法，如果這麼多的SQL查詢首先是一個愚蠢的方法......在編碼和基準測試之前。 – Jeff

數據抓取/重組速度

回答

相關問題