1樓：郭凜
不同意 @莊表偉的說法，例如像銀行結算，企業ERP這種業務對事務的需求就遠超過了對效能的需求，保證最終一致性是不夠的。而大多數網際網路應用則無所謂，發一條微博多幾個少幾個人看到其實無所謂
所以最重要的還是需求
2樓：
蘿蔔白菜各有所愛~ 有的團隊嚴格要求使用，有的不支援也不反對，有的反對使用~
只要控制好資料運營安全穩健，用與不用，個人覺得沒多大的關係。
3樓：李德逸
在網際網路應用中對於事務的應用應當謹慎，因為大量請求來臨使事務所帶來的開銷可以會導致你的應用無法響應，如果必須應用回滾，也要思考是否可以採用自建操作堆疊來回滾處理，或者採用非同步的你說的Q的方式來緩解（如果你的業務允許的話）。
4樓：李鵬
是否需要事務，是要看業務邏輯的需要。事務是保證一系列的操作同進同退，保證原子性。個人感覺應該是先分析業務需求，確定要實現那些業務邏輯，從而判斷是否需要事務。
如何分庫，在資料庫故障時如何切庫，統統這些不是決定是否需要事務的原因。反而是在確定需要事務後來考慮如何拆表分庫，如何在資料庫故障時保證資料的一致性。
什麼是資料庫事務？
大資料流動 事務是資料庫系統中的重要概念。但是事務理解起來非常的抽象，所以我們舉個栗子 轉賬是生活中常見的操作,比如從A賬戶轉賬100元到B賬號。站在使用者角度而言,這是乙個邏輯上的單一操作,然而在資料庫系統中,至少會分成兩個步驟來完成 1.將A賬戶的金額減少100元 2.將B賬戶的金額增加100元...
向資料庫插入資料時，時間欄位的值，是在程式中新增還是依賴資料庫的函式，由資料庫去管理時間？？
首先要看你的時間字段用於什麼場景。如果你要用來對賬或者做某時間段的冪等的話，也就是具有功能性業務性的，推薦還是由程式決定。因為程式本身會產生時間，和你儲存好的這種時間進行對比，必須統一由程式決定。如果與功能無關推薦資料庫來管理。這樣的話不僅能讓資料在落地的時候統一標準，還可以依賴資料庫的特性來方便的...
在分布式資料庫儲存中，資料分割槽和資料放置有什麼區別？
楊東東 資料分割槽和資料放置是邏輯和物理的關係，邏輯是頂層設計，物理是具體實現，邏輯設計決定物理實現，物理約束反過來影響邏輯設計。舉個例子，給你10個桌球，要求放入3個盒子裡。如何決定哪個球放入哪個盒子？比如 按照編號大小 0 2放入盒子A，3 5放入盒子B，6 9放入盒子C 按照編號特徵 對3取餘...