当无法进行参数化查询时,在 SQL 中查询日期的最佳实践是什么
我的简介是实现一个接口,该接口具有类似于下面的“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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为 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:
Bad habits to kick : mis-handling date / range queries
Bad Habits to Kick : Using shorthand with date/time operations
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.
如果您对任何数据库使用日期格式“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 )
我对此提供了自己的答案,尽管它偏离了问题的范围,因为这对于其他有类似问题的人来说可能是一个有用的建议。
我刚刚意识到我可以简单地期望每个实例(或世界不同地区的每个客户)可以选择在参数占位符的后半部分指定格式字符串。例如。实现:
然后我的组件根本不需要担心如何格式化日期。默认情况下,我可以使用“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:
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.