可以直接比较存储为字符串/文本的日期吗?

发布于 2024-10-27 08:28:52 字数 388 浏览 1 评论 0原文

我在 SQLite 中工作,所以我将日期存储为文本。

YYYY-MM-DD hh:mm:ss

据我所知,我应该能够对它们进行排序或将它们相互比较,就像它们不担心日期函数一样,因为任何增量都会开始向右并向左移动,就像数字一样,所有值都是数字,非数字字符始终是标准化的,我使用的是 24 小时时间。

我不断在网上看到人们提到如何将日期转换为文本以进行比较,但我不明白为什么它们不按原样工作,只要它们处于最佳状态 -> 即可。最小订单。显然我不会做数学,但是 Select DateTime From Table where DateTime > 2010-04-21 15:34:55 应该是完全可靠的,对吧?

有没有我没有想到的例外?

I'm working in SQLite so I'm storing dates as just text.

YYYY-MM-DD hh:mm:ss

As far as I can determine, I should be able to order them or compare them with each other just as they are not worrying about date functions since any incrementing starts right and moves left, just like numbers, and all the values are numeric, and the non-numeric characters are always standardized and I'm using 24-hour time.

I keep seeing people online mentioning how dates as text have to be converted for any comparisons, but I don't see why they wouldn't just work as-is so long as they're in that greatest -> smallest order. Obviously I can't do math, but Select DateTime From Table where DateTime > 2010-04-21 15:34:55 should be totally reliable, right?

Is there some exception I'm not thinking of?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

伤感在游骋 2024-11-03 08:28:52

这很好用。 SQLite 不像许多其他数据库那样具有实际的 DATE(或 DATETIME)数据类型。您可以选择以可正确排序的字符串格式存储日期(YYYY-MM-DD 或 YYYY-MM-DD hh:mm:ss),或者将日期转换为数字并存储。

如果您使用字符串格式,那么您当然必须包含引号:

SELECT DateTime FROM Table WHERE DateTime > '2010-04-21 15:34:55'

This works just fine. SQLite does not have an actual DATE (or DATETIME) data type like many other databases do. Your options are to store the date in a string format that will sort properly (YYYY-MM-DD or YYYY-MM-DD hh:mm:ss) or to convert the date to a number and store that instead.

If you use the string format, then you have to include quotes of course:

SELECT DateTime FROM Table WHERE DateTime > '2010-04-21 15:34:55'
触ぅ动初心 2024-11-03 08:28:52

在数据库中存储日期时,您看到很多提及转换的原因是大多数数据库引擎都有日期/时间的“本机”数据类型。 SQLite 没有。它建议您将日期存储为字符串或儒略日期浮点值。

此外,其他一些数据库具有相当晦涩的日期到字符串函数(我正在看着你,SQL Server ),很难弄清楚如何获取可排序的日期字符串。 SQLite 的默认日期格式 (YYYY-MM-DD HH:NN:SS) 完全可排序且易于阅读。

在比较或整理时,您可以很好地处理文本日期 - 只要您使用正确的格式,就像您所演示的那样。

事实上,您甚至可以使用 SQLite 的日期和时间函数来进行数学计算;它们相当非正统,但却出奇地灵活。

The reason you’re seeing lots of mentions of conversion when storing dates in a database, is that most database engines have a ‘native’ data type for date/time. SQLite doesn’t. It suggests you store dates as string or as julian date floating-point values.

Also, some other databases have rather obscure date-to-string functions (I’m looking at you, SQL Server), where it’s hard to figure out how to get a sortable date string. SQLite’s default date format (YYYY-MM-DD HH:NN:SS) is perfectly sortable and easy to read.

You’ll do fine with text dates when comparing or collating — as long as you use the right format, like you're presenting.

In fact, you can even do math, by using SQLite's date and time functions; they’re rather unorthodox but surprisingly flexible.

二手情话 2024-11-03 08:28:52

只要实际值符合您的预期,就可以将它们作为文本进行比较。这就是问题所在。

将日期与文本进行比较就像用剪刀奔跑一样。但 SQLite 让你一直拿着剪刀奔跑。

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

当您尝试插入或更新“2011-31-31 08:63:00”等值时,符合 SQL 标准的 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

They can be compared as text as long as the actual values are what you expect them to be. That's the problem.

Comparing dates as text is like running with scissors. But SQLite makes you run with scissors all the time.

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

A dbms that conforms to SQL standards will raise an "out of range" error when you try to insert or update values like '2011-31-31 08:63:00'. But SQLite lets you insert anything. You can even insert 'Catcall' into a datetime column. (Try it.)

SQLite gives you the same "running with scissors" behavior if you use text.

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

If values aren't what you expect them to be, you're likely to see the following kind of behavior.

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
乖不如嘢 2024-11-03 08:28:52

如果您所做的只是整理和搜索,那么应该没问题。人们多年来一直使用这种格式和文件名来达到这个目的。仅当您需要执行涉及计算的操作(例如查找特定日期后三十天内的所有记录)时,它才会开始崩溃。

If all you're doing is collating and searching, you should be fine. People have been using this format for years with file names for exactly that purpose. It should only start to break down if you need to do things that involve calculations (like find all records within thirty days of a specific date).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文