MySQL的最佳實踐問題：按ID或日期排序？

這是一個沒有問題的問題，但是我從來沒有得到過直接的答案。

MySQL的最佳實踐問題：按ID或日期排序？

假設我有以下字段和值的數據庫表：

| id | date_added   | balance | 
+------------------------------------+ 
| 1 | 2009-12-01 19:43:22 | 1237.50 | 
| 2 | 2010-01-12 03:19:54 | 473.00 | 
| 3 | 2010-01-12 03:19:54 | 2131.20 | 
| 4 | 2010-01-20 11:27:31 | 3238.10 | 
| 5 | 2010-01-25 22:52:07 | 569.40 | 
+------------------------------------+

這是一個非常基本的「佔」子系統。我想獲得最近的平衡。 id字段設置爲auto_increment。通常情況下，我會用：

SELECT balance FROM my_table ORDER BY date_added DESC LIMIT 1;

但我需要絕對確保返回的值是最新的......（見ID＃以上2 & 3）

1）我會過得更好用：

SELECT balance FROM my_table ORDER BY id DESC LIMIT 1;

2）或這會是一個更好的解決辦法？：

SELECT balance FROM my_table ORDER BY date_added,id DESC LIMIT 1;

據我所知，auto_increment效果很好，但是否足夠可靠排序的東西這個關鍵的？這就是爲什麼我認爲通過這兩個字段進行排序是一個更好的想法，但是當我在過去完成這些時，我已經看到了MySQL中一些非常古怪的行爲。或者如果有更好的解決方案，我會很感激你的意見。

在此先感謝！

布賴恩

來源

2010-01-30 DondeEstaMiCulo

如果有爲，你會得到補充與同日起的一個機會，你可能需要：

SELECT balance FROM my_table ORDER BY date_added DESC,id DESC LIMIT 1;

（注意，這兩個領域的「降」條款）。

但是，你需要考慮到要發生什麼，當有人增加了其作出之日起31 ^日一月，以保證每月的月完成月的2 ^第二調整分錄。它的ID將比2月份的^st更大。

一般來說，會計系統只是在日期工作。也許如果你能告訴我們爲什麼的順序很重要，我們可以提出其他建議。

在回答您的評論：

我很樂意聽到任何其他的想法或建議，您可能有，即使他們是題外話，因爲我有記賬型的零知識數據庫模型。

我會提供一些建議 - 這是我能夠立即想到的，我通常會用更少的鼓勵來發出更多的「建議」:-)前兩個，更多與數據庫相關的會計-relared，分別是：

首先，做一切在第三範式和只有恢復，如果當你有性能問題。這可以爲你節省很多的重複數據，可能會失去一步的焦慮。即使您還原了，也可以使用觸發器和其他DBMS功能來確保數據不會失步。

舉個例子，如果你想加快你在last_name列的搜索速度，你可以創建一個upper_last_name列（索引），然後使用它來定位匹配你已經上位的搜索詞的記錄。這幾乎總是比每行功能upper(last_name)快。您可以使用插入/更新觸發器來確保upper_last_name始終正確設置，並且僅當名稱更改時纔會產生成本，而不是每次搜索時都會產生成本。

其次，除非您可以使用相同的觸發器類型的技巧來保證數據不會失步，否則不要在表中重複數據（如您當前的模式）。當您向客戶發送最終餘額不符合起始餘額和購買額的發票時，您的客戶會做什麼？這不會讓你的公司看起來很專業:-)

第三（這是更會計相關），你通常不需要擔心在動態計算餘額時的交易數量。這是因爲會計系統通常在年底有翻轉功能，重置期初餘額。

因此，您通常不需要一次處理一年以上的數據，除非您是美國政府或微軟，否則不會那麼繁瑣。

來源

2010-01-30 03:59:55 paxdiablo

謝謝Pax！實際上我有一個字段不在表格中，這就是user_id。我們有一個「信用」系統，我們的用戶可以用它來購買商品或服務，並且我們在這張表中保留了其餘額。爲了獲得他們的'當前餘額'，我想從這個特定的表中選擇最近的餘額。上面的表格在進行交易時更新。（交易全部存儲在單獨的表格中）。我希望這是有道理的，哈哈。 – DondeEstaMiCulo 2010-01-30 04:04:36

嗯，這不是我會這樣做的方式，而是各自爲戰:-)我要麼根據他們所有的交易條目計算餘額（我的偏好，因爲有*沒有*數據越來越不合適這兩個表），或者只是爲每個用戶保留* 1 *記錄並且更新它。事實上，我現在無法推薦第二種選擇，現在我想到了它。您還需要小心使用當前的解決方案，因爲您將數據保存在兩個彼此不同的地方。 – paxdiablo 2010-01-30 04:07:28

那麼我們想保持平衡歷史，如果沒有別的，但內部報告的目的。我實際上已經考慮過你計算所有交易的想法，但是通過上述方法可能會更容易。也許我會重新考慮這個想法。 ;）我很樂意聽到您可能有的任何其他想法或建議，即使它們是脫離主題，因爲我對會計類型數據庫模型沒有任何認識。 ;）再次感謝！ – DondeEstaMiCulo 2010-01-30 04:15:24

就我個人而言，我永遠不會信任這種自動增量。我按日期排序。

我很確定這個ID是保證唯一的，但不一定是連續的和增加的。

來源

2010-01-30 03:58:53 MikeW

MySQL的auto_increment永遠不會插入一個比它插入的最後一個數字更低的數字。如果您需要數據庫中的最新事務，那麼依賴它是一個安全的數字。 – 2014-03-10 15:26:09

也許是由id更快，但更安全的日期時間;使用後者如果有性能問題添加索引。

來源

2010-01-30 04:00:45

MySQL的最佳實踐問題：按ID或日期排序？

回答

相關問題