1樓：
首先要看你的時間字段用於什麼場景。
如果你要用來對賬或者做某時間段的冪等的話，也就是具有功能性業務性的，推薦還是由程式決定。
因為程式本身會產生時間，和你儲存好的這種時間進行對比，必須統一由程式決定。
如果與功能無關推薦資料庫來管理。
這樣的話不僅能讓資料在落地的時候統一標準，還可以依賴資料庫的特性來方便的實現一些功能，例如default
2樓：豬頭小隊長
推薦用資料庫的，應用伺服器的可能有很多臺，如果管理不嚴格，每台伺服器之間可能有時間差，有多條時間線，事件的前後順序就難說了，資料庫就沒有這個問題，即使時間是錯的，但是時間線只有一條，能分清前後
3樓：frank wang
如果你的程式只支援一種資料庫，可以用資料庫的函式。
支援三種，就有點麻煩了，要是8種呢？豈不要崩潰？
JDBC 可以幫你處理這個問題，其他比較成熟的語言也會有類似JDBC 解決方案。
4樓：飛鳥
能讓資料庫管理的時間字段，盡量讓資料庫管理，因為速度快，時間精確。舉例：某個字段記錄的是上次修改時間或記錄建立時間，這時毫無疑問，讓資料庫管理這個字段。
不能讓資料庫管理的時間字段，你沒有選擇，只能由業務提供。舉例：下次會議開始時間。
在JAVA程式插入資料庫時,時間應該取JVM的時間還是資料庫的時間 這兩個時間可能不一致 可能會造成什麼風險
li kyle 這是乙個設計問題，而設計源於需求，首先要搞清楚的是業務需求就是說這個時間是幹什麼用的，脫離這個談從哪兒取時間就沒有實際意義了比如你要記錄業務發生的時間 才發現草稿箱裡3年前的草稿，完成並提交吧 這個如何能用資料庫時間呢？如果考慮到國際化不同時區，直接用JVM時間也是不行的 但是如果你...
無限的向資料庫插入資料會怎麼樣？
知來吹 既然說是面試，我就告訴你我會怎麼瞎扯的。不一定錯也不一定是對的。首先資料庫肯定可以被無限插入，這個是沒次數限制的。唯一限制的是他的資料庫大小和硬體的條件。資料庫有大小的情況下，資料都是計算大小的。肯定就無法繼續在插入到資料庫了。所以這個問題解決了。對不 有毛病嗎？下次就這樣懟回去，明顯是看你...
華為向Oracle SAP下戰書 發布資料庫替換Salesforce
Shadow 目前沒什麼比較完美的匹配機制，基本上乙個分數段的實力差距其實很大。我坑了人心裡是有數的，道個歉一般別人也不會抓著你不放。講真的，寧可我坑別人也不想別人坑我，一晚上全是坑，開局就走在翻盤路上誰也受不了。另外自己技術怎麼養胃樣有點數，我覺得最近幾把不對勁，我都屬於坑的時候我會主動玩輔助做視...