在关系数据库中存储非特定日期（例如“1997 年秋季”）
我正在解析一个文本文档并将大部分数据转换为关系格式。整个过程中使用了多种日期格式，其中之一是“Fall 1997”。
存储这些信息的最佳方法是什么，这些信息在某种意义上是非特定的（不是绝对日期），同时又不失去“秋季”确实提供的粒度？
作为附加信息：我的特定数据库是 MySQL。
I am parsing a text document and converting much of the data into a relational format. A variety of date formats are used throughout, but one of these is "Fall 1997".
What would be the best way to go about storing this information, which is non-specific in one sense (not an absolute date), without losing the granularity that "fall" does provide?
As additional info: my specific database is MySQL.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我见过多种技术，但如果不直接将其加载到 varchar 中，您就必须决定范围。您可以使用包含 1997-09-01 的常规日期列，但用指示特殊性的列对其进行扩充 - 'S' 表示季节（使用 3、6、9、12 月份的第一个月），'Q' 表示季度（使用第 1、4、7、10 个月的第一个月）或其他。对于学期之类的事情也是如此。
在解释此类日期时 - 特别是“此事件是在某个时间之前还是之后发生”时，您必须决定如何处理它们。就像整个经期是否必须在约会之前一样。
您可以将此类“日期”转换为周期表中的条目，并包含说明以及开始日期和结束日期，然后链接到该周期。那么 Fall 1997 是一个数据库实体，因为它被明确定义为表中的一行，并且其他行具有其外键。这并不消除对逻辑来决定有关这些日期的事情的需要，但这确实意味着此类逻辑可以是表驱动的。
在我打电话之前，更多地取决于使用场景和数据种类。
There are various techniques I've seen, but without loading it in straight varchar, you'll have to decide on the scope. You can use a regular date column containing 1997-09-01 but augment it with a column which indicates the specificity - 'S' for season (using the firsts of months 3, 6, 9, 12) 'Q' for quarter (using the firsts of months 1, 4, 7, 10) or whatever. Similarly for semesters and things like that.
When interpreting such dates - particularly in "did this event happen before or after a certain time", you have to decide how to handle them. Like whether the whole period has to come before a date.
You can convert such a "date" to an entry in a period table with a description and a start and end date and then link to the period. Then Fall 1997 is a database entity in the sense that it is well defined as a row in a table and other rows have foreign keys to it. This does not remove the need for logic to decide things about these dates, but it does mean that such logic can be table driven.
It would depend a lot more on the usage scenarios and the variety of data before I would make a call.