「為了能在orderdetail的orderid欄位中添入正確的值，必須先更新order表以獲取到系統為其分配的orderid值，然後再用這個orderid填充orderdetail表。最後更新oderdetail表。但是，為了確保資料的一致性，order與orderdetail在更新時必須在事務保護下同時進行，即確保量表同時更行成功。顯然它們是相互矛盾的。」
我覺得此處的矛盾是的可以解決的，正在處理的乙個erp專案中，好幾個表的插入是如此處理的，具體處理是：
1、程式中建乙個大事物，包含主表和從表的插入。
2、主從表插入都有儲存過程完成，主表儲存過程成功後,返回正確的id值,進行從表的插入;如果不成功主表就給出乙個-1,表示不成功,則程式控制不插從表.
3、只有主從表插入都成功，大事物才進行提交。
當然要注意一些細節：
1、要考慮使用者的擴充套件性：
原因是：客戶本來只有乙個部分有訂單操作，如果現在要有兩個部門，訂單編號又要聯號，你將不能操作。
談資料庫主鍵選取策略
int和guid，究竟選誰？關於資料庫主鍵的選取策略，大家都是在int和guid兩者中徘徊。忘了那些喋喋不休的爭論吧！畢竟魚與熊掌，不可兼得。在這篇文章中，我們不再關注它們的優缺點，自覺先行做點功課哦！如小標題，如果真要選，我會選誰？肯定地說，我會選guid，又或者兩者都選上。後者情形下，使用gui...
mysql的主鍵策略 談資料庫主鍵選取策略
int和guid，究竟選誰？如小標題，如果真要選，我會選誰？肯定地說，我會選guid，又或者兩者都選上。後者情形下，使用guid做主鍵 int做小二，int在業務層生成，這要即使重複了，也不礙事，且int是要反饋給前端的，定時做乙個防衝突檢測。如果讓使用者記憶或反饋那guid字串 去連線字元後32位...
資料庫主鍵生成策略
在建立資料庫的時候，需要為每張表指定乙個主鍵，所謂主鍵就是能夠唯一標識表中某一行的屬性或屬性組，乙個表只能有乙個主鍵，但可以有多個候選索引。因為主鍵可以唯一標識某一行記錄，所以可以確保執行資料更新 刪除的時候不會出現張冠李戴的錯誤。資料庫的主鍵生成有多種方式，每種方式都有其優點和缺點，應該根據不同的...