為什麼圖數據庫不擅長 CRUD 操作？
我聽說圖形數據庫在 CRUD 操作方面天生就比關係數據庫差。這是真的？如果是，那是為什麼？
一些想法：
要在 realtional DB 中進行 crud 操作，您基本上必須使用一行（最好的情況）。只要它不是面向列的格式 (OLAP)，這應該是非常有效的。
據我所知，有兩種流行的方式來儲存圖表：
要麼實際儲存“指向彼此的對象”。這將是圖的自然表示。
或者儲存一個列出關係的表。這將是圖的非自然表示。
在第二種情況下，我理解為什麼 crud 操作很慢：您可能必須接觸很多表來表示關係模式中單行的更新。
為什麼在第一種情況下它很慢？要更新或刪除，您可能只需要創建/讀取/更新/刪除單個對象。
我認為該軟體太複雜，無法對這個問題給出簡單的是/否的答案。它還取決於您如何定義 CRUD。
我們以“下單”功能為例。從業務的角度來看，這是一個單一的原子操作。然而，在規範化的關係數據庫中，它可能會涉及許多表。訂單會有一個插頁；可能會更新客戶或購物車錶；讀取許多相關表以確保引用正確性。所有這些語句都將（應該？）包裝在數據庫事務中。因此，單個業務操作變成了包裝在單個數據庫事務中的多個數據庫語句。
如果使用文件數據庫而不是關係數據庫，則可能只有一次寫入。圖 DBMS 將位於這兩者之間，根據特定應用程序的架構或多或少地進行規範化。
只看磁碟結構，討論也更加細緻入微。向表中插入一行似乎很簡單。如果有索引，那麼很可能會有寫放大。如果存在索引拆分，則更是如此。如果該行包含 BLOB，則這些 BLOB 可能儲存在單獨的資料結構或不同的文件中。可以通過觸發器或物化視圖進行級聯操作。壓縮和加密可能會導致大量 CPU 消耗。
有許多磁碟結構來支持類似圖形的處理。一個節點是基本對象，邊成為節點的屬性。邊緣作為指針列表儲存在邊緣任一端的節點中。因此，創建一個節點將是一次寫入。創建邊緣將是兩個。插入帶有外鍵約束的行（最接近邊緣的等價物）將是讀取和寫入。
在閱讀方面，也有鞦韆和迴旋處。按父項計運算元行將是關係世界中的兩個表連接。如果邊緣指針作為列表儲存在節點內，則它是單個節點列表掃描。在圖形數據庫中，執行 is-that-connected-to-this 查詢（認識的人的朋友住在同一個城市的人可以在一小時內乘火車到達）很容易；這在關係世界中是可怕的。對於 CRUD 的“R”位，對於傳遞查詢，圖每次都勝出。
總之，我質疑標題的前提。如果毫秒在您的上下文中很寶貴，那麼在生產等效硬體上進行大規模測試。