使用 MySQL Date/Time 類型

來源:互聯網
上載者:User

由於曾經和他是同一個團隊的,所以對於其我很熟悉他那“潔癖”的做法,對於他的很多的觀點我也非常的贊同;但是有一件非常不理解的地方就是設計資料庫的時候總是會迴避使用 Date/Time 類型。他的做法是將時間相關的欄位設定為 INT(10) 類型,然後用 UNIX 時間戳記來儲存。而我本人對於這點做法非常的不贊同:

首先,是類型操作的不同,類似於 wiLdGoose 這樣做法的“時間計算”實質上是整形之間的操作(而且這個整形非常大,長度為 10)。更有甚者,將時間戳記設定為 VARCHAR(10) ,由此引發的效率問題不言而喻。

至於時間計算和整形計算乃至字串的計算的效率問題,這篇文章非常能說明問題。

其次,是邏輯方面的操作問題。這是使用時間類型的優勢,尤其是在需要高精度的項目上。比如需要“前一個星期的資料”和“獲得從資料庫建立以來每個星期一的資料”,這樣的操作如用 wiLdGoose 兄的做法複雜度可想而知。

最後,就是直觀不直觀的問題,可以理解的是我們的大腦是不會直接將這一大串的時間戳記轉換成日期格式的。相比而言,直接使用時間類型明顯就直觀得多(它本身就是時間格式)。

而我目前的團隊也還是在使用類似的方法。本人對於類似技術細節也爭執了良久,但由於崗位和決定權的問題,團隊還是無法採納本人的意見,甚為遺憾。

MySQL 定位為簡單快速的 DBM 自然能迅速的駕馭,但是另一方面很容易造成不會深入下去的局面。對於此,我們更應該注意每一項的資料庫設計細節,一項產品不斷添加新的功能到最後都是面嚮應用的。

最後,附 MySQL 官方的時間和日期函數的手冊。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.