当无法进行参数化查询时,在 SQL 中查询日期的最佳实践是什么

发布于 2024-12-06 05:40:10 字数 722 浏览 0 评论 0原文

我的简介是实现一个接口,该接口具有类似于下面的“GetValuesSqlStatement”的方法:

public string SqlPattern { get { ... } }
//this varies; eg. "SELECT name FROM someTable WHERE startDate < {0}"

public string DatabaseType { get { ... } }
//this varies; eg. "SqlServer"

public string GetValuesSqlStatement(List<object> paramValues)
{
    //...desired logic here, using DatabaseType, SqlPattern and paramValues
}

现在,因为这必须生成可执行的 SQL 语句,所以我不能在查询执行中使用参数。我必须实现的接口是没有商量余地的。确保数据库查询引擎正确解释结果中的日期的最佳方法是什么?假设 paramValues 包含 .NET DateTime 对象,那么在插入 SQL 模式字符串之前应如何将它们格式化为字符串?必须数据库中最常见的通用日期格式是什么? (例如,类似“dd-mmm-yyyy”)。

注意:我只需要担心 2005 年以后的 Sql Server 和 Oracle 10g 以后的版本。因此 SQL 必须是有效的 T SQL 和 PL SQL,并且在两种风格中含义相同。

My brief is to implement a interface which has a method that looks something like 'GetValuesSqlStatement' below:

public string SqlPattern { get { ... } }
//this varies; eg. "SELECT name FROM someTable WHERE startDate < {0}"

public string DatabaseType { get { ... } }
//this varies; eg. "SqlServer"

public string GetValuesSqlStatement(List<object> paramValues)
{
    //...desired logic here, using DatabaseType, SqlPattern and paramValues
}

Now, because this must produce an executable SQL statement, I can't use parameters in the execution of the query. And the interface I must implement is non-negotiable. What is the best way to proceed to make sure the dates in the result are interpreted by the database query engine correctly? Assuming that the paramValues contain .NET DateTime objects, how should these be formatted to string before plugging into the SQL pattern string? What is the most common universal date format across must databases? (eg. something like 'dd-mmm-yyyy').

NB: I only really need to worry about Sql Server from 2005 onwards and Oracle 10g onwards. So the SQL must be valid T SQL and PL SQL and mean the same thing in both flavours.

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

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

发布评论

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

评论(3

对你而言 2024-12-13 05:40:10

我认为 SQL Server 唯一明确的日期格式是 YYYYMMDD:

Oracle 使用 DATE 'YYYY-MM-DD' 表示法:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements003.htm#BABGIGCJ

虽然可能有一种符号在某些情况下适用于两者,但我怀疑有一种方法适用于所有可能的区域服务器设置。

就像你说的,YYYY-MON-DD 可能有用 - 这是 Oracle 的默认值。

I think the only unambiguous date format for SQL Server is YYYYMMDD:

Oracle uses a DATE 'YYYY-MM-DD' notation:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/sql_elements003.htm#BABGIGCJ

While there may be a notation which works for both in some scenarios, I doubt there is one which works for both with all possible regional server settings.

Like you said, YYYY-MON-DD might be useful - it's Oracle's default.

内心旳酸楚 2024-12-13 05:40:10

如果您对任何数据库使用日期格式“yyyy-mm-dd”,那么应该没问题。这是根据 ISO 8601 (http://www.iso.org/iso/date_and_time_format )

If you use date format 'yyyy-mm-dd' with any DB you should be fine. This is as per ISO 8601 ( http://www.iso.org/iso/date_and_time_format )

━╋う一瞬間旳綻放 2024-12-13 05:40:10

我对此提供了自己的答案,尽管它偏离了问题的范围,因为这对于其他有类似问题的人来说可能是一个有用的建议。

我刚刚意识到我可以简单地期望每个实例(或世界不同地区的每个客户)可以选择在参数占位符的后半部分指定格式字符串。例如。实现:

public string SqlPattern { get {
    return "SELECT name FROM someTable WHERE startDate < {0:yyyy-mm-dd}";
} }  

然后我的组件根本不需要担心如何格式化日期。默认情况下,我可以使用“yyyymmdd”,或者更好的是使用服务器的区域性来选择默认值。否则使用自定义指定的模式。这将是一种通用方法,适用于也需要格式化为 SQL 字符串的其他类型。

I'm providing my own answer to this, even though it's veering from the scope of the question because it might be a useful suggestion for others with a similar question.

I just realised I can simply expect each instance (or each customer in a different part of the world) to optionally specify a format string in the latter part of the parameter place-holder. Eg. implementation:

public string SqlPattern { get {
    return "SELECT name FROM someTable WHERE startDate < {0:yyyy-mm-dd}";
} }  

And then my component doesn't need to worry about how to format the date at all. By default I can use 'yyyymmdd' or even better just use the server's culture to pick a default. Otherwise use the custom-specified pattern. This would be a generic approach applicable to other types that need to be formatted out to a string for SQL too.

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