|
|
首先，是類型操作的不同，類似于 wiLdGoose 這樣做法的“時(shí)間計(jì)算”實(shí)質(zhì)上是整形之間的操作（而且這個(gè)整形非常大，長度為 10）。更有甚者，將時(shí)間戳設(shè)置為 VARCHAR(10) ，由此引發(fā)的效率問題不言而喻。
至于時(shí)間計(jì)算和整形計(jì)算乃至字符串的計(jì)算的效率問題，這篇文章非常能說明問題。
其次，是邏輯方面的操作問題。這是使用時(shí)間類型的優(yōu)勢，尤其是在需要高精度的項(xiàng)目上。比如需要“前一個(gè)星期的數(shù)據(jù)”和“獲得從數(shù)據(jù)庫建立以來每個(gè)星期一的數(shù)據(jù)”，這樣的操作如用 wiLdGoose 兄的做法復(fù)雜度可想而知。
最后，就是直觀不直觀的問題，可以理解的是我們的大腦是不會(huì)直接將這一大串的時(shí)間戳轉(zhuǎn)換成日期格式的。相比而言，直接使用時(shí)間類型明顯就直觀得多（它本身就是時(shí)間格式）。
而我目前的團(tuán)隊(duì)也還是在使用類似的方法。本人對于類似技術(shù)細(xì)節(jié)也爭執(zhí)了良久，但由于崗位和決定權(quán)的問題，團(tuán)隊(duì)還是無法采納本人的意見，甚為遺憾。
MySQL 定位為簡單快速的 DBM 自然能迅速的駕馭，但是另一方面很容易造成不會(huì)深入下去的局面。對于此，我們更應(yīng)該注意每一項(xiàng)的數(shù)據(jù)庫設(shè)計(jì)細(xì)節(jié)，一項(xiàng)產(chǎn)品不斷添加新的功能到最后都是面向應(yīng)用的。
最后，附 MySQL 官方的時(shí)間和日期函數(shù)的手冊。
php技術(shù)：使用 MySQL Date/Time 類型，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
