消息傳遞應用程序的復雜SQL查詢

Question

我正在使用PostgreSQL 9.3.4在Django 1.6.2應用程序中構建消息傳遞功能。 在用戶的“消息”主頁上，我將顯示一個用戶與其他用戶的對話列表。 每個對話“平鋪”或塊將顯示該對話中另一個用戶的圖片和名稱，該對話中最后一條消息的發送日期以及該最后一條消息中的前25個字符。 如果最后一條消息是由正在查看這些對話的用戶發送的，我還將顯示一個小的“答復”圖標。 我已經查詢到可以識別查看器與所有其他用戶之間的所有對話的地步，但是我在從“用戶”和“消息”表中提取所需字段時遇到了麻煩。

我的表格（顯示在底部）是用戶，消息和對話。 盡管我已經實現了表模式，以便用戶和會話之間存在多對多關系，但一開始我將創建我的界面，以便用戶只能向其他用戶發送消息，而不能多個用戶。

當我對下面顯示的數據運行查詢時，我要獲取的是用戶3、4、5的對話和用戶ID以及相關的用戶名，對話中的最后一條消息，發送者以及發送日期。 相反，我得到了錯誤：

 ERROR: syntax error at or near "WHERE" 

誰能幫我解決這個問題？ 我對速度比對優雅更感興趣。

測試用例

對話用戶鏈接表中的數據：

 id | conversation_id | user_id 
----+-----------------+---------
  1 |               1 |      32
  2 |               1 |       3   <- want this
  3 |               2 |      32
  4 |               2 |       4   <- want this
  6 |               3 |       3
  7 |               3 |       1
  8 |               4 |      32
  9 |               4 |       5   <- want this
 10 |               5 |       7
 11 |               5 |       9

我要返回的行。 每個消息是該會話中的最后一條消息。

conversation_id | user_id | username  | from_user | message | send_date
----------------+---------+-----------+-----------+---------+----------
 1              | 3       | user3     | u3 or u32 | <msg3>  | <date>
 2              | 4       | user4     | u4 or u32 | <msg4>  | <date>
 4              | 5       | user5     | u5 or u32 | <msg5>  | <date>

查詢無效：

SELECT cu.conversation_id,
       cu.user_id,
       au.username,
       m.from_user,
       m.message,
       m.send_date
FROM conversation_user cu
INNER JOIN auth_user au ON cu.user_id = au.id
INNER JOIN message m ON cu.conversation_id = m.conversation_id
ORDER BY m.send_date DESC LIMIT 1
WHERE conversation_id IN
    (SELECT conversation_id
     FROM conversation_user
     WHERE user_id = 32)
  AND user_id != 32;

表定義

# auth_user
--------------+--------------------------+------------------------------
 id           | integer                  | not null default nextval(...
 username     | character varying(30)    | not null
Referenced by:
    TABLE "conversation_user" CONSTRAINT "conversation_user_user_id_fkey" FOREIGN KEY (user_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "message" CONSTRAINT "message_from_user_id_fkey" FOREIGN KEY (from_user_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED

# conversation
------------+--------------------------+--------------------------------
 id         | integer                  | not null default nextval(...
 start_date | timestamp with time zone | not null
Referenced by:
    TABLE "conversation_user" CONSTRAINT "conversation_id_refs_id_4344ca71" FOREIGN KEY (conversation_id) REFERENCES conversation(id) DEFERRABLE INITIALLY DEFERRED
    TABLE "message" CONSTRAINT "message_conversation_id_fkey" FOREIGN KEY (conversation_id) REFERENCES conversation(id) DEFERRABLE INITIALLY DEFERRED

# conversation_user
-----------------+---------+--------------------------------------------
 id              | integer | not null default nextval(...
 conversation_id | integer | not null
 user_id         | integer | not null
Foreign-key constraints:
    "conversation_id_refs_id_4344ca71" FOREIGN KEY (conversation_id) REFERENCES conversation(id) DEFERRABLE INITIALLY DEFERRED
    "conversation_user_user_id_fkey" FOREIGN KEY (user_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED

# message
     Column      |           Type           |
-----------------+--------------------------+---------------------------
 id              | integer                  | not null default nextval(...
 conversation_id | integer                  | not null
 from_user_id    | integer                  | not null
 to_user_uid     | integer                  | not null
 message         | text                     | not null
 send_date       | timestamp with time zone | not null
Foreign-key constraints:
    "message_conversation_id_fkey" FOREIGN KEY (conversation_id) REFERENCES conversation(id) DEFERRABLE INITIALLY DEFERRED
    "message_from_user_id_fkey" FOREIGN KEY (from_user_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED

Answer 1

修正語法

基本上，您只需要將WHERE條件移動到適當的位置，如@Lamak注釋 ：

SELECT  ...
FROM conversation_user cu
INNER JOIN ...
WHERE conversation_id IN (SELECT conversation_id FROM conversation_user WHERE user_id = 32) AND user_id != 32
ORDER BY m.send_date DESC
LIMIT 1;

快一點

根據評論：

我正在嘗試選擇用戶32進行的每個對話中的最后一條消息。

SELECT cu.conversation_id
     , ufrom.username AS from_user
     , uto.username   AS to_user
     , m.message
     , m.send_date
FROM   conversation_user cu
LEFT   JOIN LATERAL (
   SELECT from_user_id, to_user_id, message, send_date
   FROM   message   m
   WHERE  m.conversation_id = cu.conversation_id
   ORDER  BY send_date DESC
   LIMIT  1
   ) m ON TRUE
LEFT   JOIN auth_user ufrom ON ufrom.id = m.from_user_id
LEFT   JOIN auth_user uto   ON uto.id = m.to_user_id
WHERE  cu.user_id = 32;

筆記

• 聯接通常比子查詢上的IN構造更快，尤其是對於大集合而言。 但是您也不需要。 您已經使事情復雜化了。

• 您可以使用DISTINCT ON進行更簡單的查詢，但我希望此查詢會更快。
  細節：

  • 在每個GROUP BY組中選擇第一行？
  • 優化GROUP BY查詢以檢索每個用戶的最新記錄

數據庫設計

• 該查詢假定(user_id, conversation_id)為UNIQUE您已在注釋中確認了這一點 。 確保添加實際的UNIQUE約束，該約束會自動提供急需的索引。

• message上的索引(conversation_id, send_date DESC)也將有所幫助。 細節：

  • 復合索引對第一字段的查詢是否也有用？

• 假設auth_user.id是PK，那么它將被索引。

• message.to_user_uid可能應該是to_user_id ，例如from_user_id 。

• 您可能想要添加另一個FK來保持一致：

   "message_to_user_id_fkey" FOREIGN KEY (to_user_id) REFERENCES auth_user(id) 

  不知道為什么您認為自己需要DEFERRABLE INITIALLY DEFERRED 。 如果您不知道需要此功能，請將其刪除。 這是出於特殊目的，使常規操作的成本更高。

• 如果只有兩個用戶可以參加同一對話 ，則完全刪除 conversation_user user1並添加user1和user2或類似於conversation將更為有效-除非用戶/對話的每種組合都有更多的屬性。 也可能簡化message 。 您只需要布爾信息，而不是from_user和to_user 。
  根據關系理論， conversation可以看作是表auth_user與自身之間多對多關系的一種實現。