代码之家  ›  专栏  ›  技术社区  ›  Konerak

MySQL日期字段:重复还是计算?

  •  1
  • Konerak  · 技术社区  · 15 年前

    我们使用的是一张10多年前强加给我们的桌子。我们可以添加列,但是 敦促不要更改现有列 .

    某些列用于表示日期,但格式不同。其中包括:

     * CHAR(6): YYMMDD
     * CHAR(6): DDMMYY
     * CHAR(8): YYYYMMDD
     * CHAR(8): DDMMYYYY
     * DATE
     * DATETIME
    

    由于我们现在想使用高级日期函数进行一些更复杂的查询,我的经理建议 复制那些问题列 使用日期或日期时间格式转换为正确格式的列。

    这是去的路吗? 我们不能每次访问列时都使用str-to-date函数吗? ?为了避免每个查询都必须复制粘贴函数,我仍然可以使用视图或存储过程,但是复制数据以避免重新计算听起来是错误的。

    我看到的解决方案(我想我更喜欢2.2.1)

    1. Physically duplicate columns
    1.1 In the same table
    1.1.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...)
    1.1.2 Maintained by a trigger on each modification
    1.2 In a separate table
    1.2.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...)
    1.2.2 Maintained by a trigger on each modification
    2. On-demand transformation
    2.1 Each query has to perform the transformation
    2.1.1 Using copy-paste in the source code
    2.1.2 Using a library
    2.1.3 Using a STORED PROCEDURE
    2.2 A view performs the transformation 
    2.2.1 A separate table replacing the entire table
    2.2.2 A separate table just adding the date-fields for the primary keys
    

    我说得对吗 重新计算比存储更好 ?会吗? 看法 是一个好的解决方案?

    1 回复  |  直到 15 年前
        1
  •  1
  •   Konerak    15 年前

    我一直在 测试 整个早上。我把桌子复制了两次:

    • 一次使用视图 将varchar字段转换为 每个查询的日期字段,使用 串日
    • 一次用于添加列并使用str_to_date进行更新

    后来我提出了很多不同的问题- 视图执行速度慢一点 ,如预期的那样,但只有几十毫秒。

    因为存储额外的列需要额外的7MB(这对磁盘使用和RAM使用有影响),而且我们的服务器有CPU的备用能力,而不是RAM/IO, 我倾向于“在每个查询中将char转换成日期” 解决方案。

    我不确定是否要使用视图、存储过程,或者只是在我要编写的每个查询中输入str_日期,但这更像是一种“编码最佳实践”,而不是一种优化。