我在SQLite中工作，所以我將日期存儲爲文本。可以直接比較存儲爲字符串/文本的日期嗎？
YYYY-MM-DD hh:mm:ss
至於我能決定，我應該能夠對它們進行排序或將它們相互比較，正如他們擔心的不是最新功能，因爲任何遞增開始左右移動，就像數字，並且所有值都是數字，並且非數字字符總是標準化的，我使用的是24小時制。
我一直在網上看到人們提及日期作爲文本必須轉換爲任何比較，但我不明白爲什麼他們不會像現在這樣工作，只要他們在最大 - >最小訂購。顯然我不能做數學，但Select DateTime From Table where DateTime > 2010-04-21 15:34:55應該是完全可靠的，對吧？
有沒有一些例外，我沒有想到？
當在數據庫中存儲日期時，您看到大量提及轉換的原因是大多數數據庫引擎都具有日期/時間的「本機」數據類型。 SQLite沒有。它建議你將日期存儲爲字符串或朱利安日期浮點值。
此外，其他一些數據庫的日期到字符串函數（我看着你，SQL Server），它很難弄清楚如何獲得一個可排序的日期字符串相當模糊。 SQLite的默認日期格式（YYYY-MM-DD HH：NN：SS）完全可以排序並且易於閱讀。
比較或整理時，你會很好地處理文本日期 - 只要你使用正確的格式，就像你提出的那樣。
事實上，你甚至可以通過使用SQLite的date and time functions來做數學計算;他們相當非正統，但卻非常靈活。
這工作得很好。與許多其他數據庫一樣，SQLite沒有實際的DATE（或DATETIME）數據類型。您的選項是以字符串格式存儲日期，以便正確排序（YYYY-MM-DD或YYYY-MM-DD hh：mm：ss）或將日期轉換爲數字並存儲。
如果使用字符串格式，那麼你必須包括課程的報價：
SELECT DateTime FROM Table WHERE DateTime > '2010-04-21 15:34:55'
超級，把字符串放在單引號中的技巧拯救了我的一天。一直在尋找解決方案..謝謝 – Saqib 2015-03-04 10:57:54
他們可以爲文本，只要實際值是你所期望的是什麼進行比較。那就是問題所在。
比較文本的日期就像用剪刀跑。但是SQLite讓你隨時都可以用剪刀來運行。當您嘗試插入或如「2011-31-31 08:63:00」更新值
符合SQL標準sqlite> create table test (d1 datetime primary key);
sqlite> insert into test values ('2011-31-31 08:63:00');
sqlite> select * from test;
2011-31-31 08:63:00
一個DBMS將引發一個「超出範圍」的錯誤。但SQLite讓你插入任何東西。您甚至可以將'Catcall'插入到日期時間列中。 （試一試。）
如果您使用文本，SQLite會爲您提供與「剪刀運行」相同的行爲。
sqlite> create table test (d1 varchar(25) primary key);
sqlite> insert into test values ('2011-31-31 08:63:00');
sqlite> select * from test;
2011-31-31 08:63:00
如果值不是您所期望的那樣，您可能會看到以下類型的行爲。
sqlite> create table test (d1 varchar(25), d2 varchar(25));
sqlite> insert into test values ('2011-01-01 08:00:00', '2011-01-01 08:15:00');
sqlite> select d1<d2 from test;
1
sqlite> update test set d2 = '2011+01-01 08:15:00';
sqlite> select d1<d2 from test;
0
公平起見，'Catcall'永遠不會插入SQLite中的'datetime'列;相反，該列將是一個文本列。而且，只要我們使用剪刀運行，就可以在varchar（25）列中插入儘可能多的文本，因爲SQLite不會遵守定義的25字符限制。 – 2011-03-30 16:58:56
如果你只是在整理和搜索，你應該沒問題。人們多年來一直在使用這種格式的文件名來達到這個目的。如果您需要執行涉及計算的事情（如在特定日期的三十天內查找所有記錄），它只應該開始分解。
好極了！我看不出有什麼理由不這樣做...... – Damon 2011-03-30 21:43:25