数据库设计原则

数据库设计原则

第一章 表设计

1.   使用日期类型保存日期数据

有许多大型系统的数据库都使用字符类型来存储日期；甚至有许多教师和有经验的开发者也认为应该使用字符类型而不是日期类型来存储日期。是的，使用字符类型来存储日期确实可以获得许多便利。但是，有一个原则，必须要保证

所有以字符类型保存着的日期数据都必须是有效的，并且具有相同的格式。

想象一下“学生”表中有如下数据：

 

出生日期

-----------------

1980-5-6

1981-6-18

1979/3/15

80-2-16

79-02

 

现在，需要统计所有在2月份出生的人数，能办到么？

好了，对于天才程序员外加 SQL高手的你来说，上面的任务只是小菜一碟，不过我们还是别在那上面浪费时间了。

我们经常做的就是客户端验证。也就是在把某人的[出生日期]保存进数据库之前，先对其有效性进行验证，再把这个有效的日期以固定的格式（如yyyy-mm-dd）保存。这让我联想到了人的免疫系统――它很有效，但不总是有效。

也许你的系统中有很多个日期字段，有很多处用于更新这些字段的代码，你真的能保证所有的更新之前都作了验证么？我相信如此细心负责的你能够做到，但是你能保证项目组中的所有人都能做到么？我相信你所在的精英团队能做到。不过别忘了，你的数据来源并不完全来自用户输入，很可能需要从别的数据库导入，甚至从Excel表中导入。最后，在系统成功运行若干个月后，可能会有其他的系统可以更新你的数据库。现在，你还能保证么？

是的，有时候你就是不能保证[出生日期]有一个数据是“2005-5”（因为用户觉得有月份就足够了），然后，很不幸地，你的程序在把这个字符串转换为日期时崩溃了。天哪，这不是你的错，可是数据库中已经有一大堆这样的数据了。于是，你用了一个小时写了一个Oracle函数SMART_TO_DATE()，它可以转换形如1980-5-6和2005-5这两种格式的日期，然后你把原来的“TO_DATE(出生日期,’yyyy-mm-dd’)”改为“SMART_TO_DATE(出生日期)”。呵，天下太平了。而且既然你已经花了不少心血写了一个如此强大的函数，你就可以继续纵容用户继续填写非标准的日期，而非标准的日期越多，你的SMART_TO_DATE()就必须越“SMART”，然后考验你的SMART的非标准日期格式就越多…一旦你陷入这样的负反馈循环中，你就不会再继续深爱着你的系统了，而且你的心脏会越来越痛，最后你的爱和生命都没有了，天下间最悲惨的事莫过于此，而这仅仅是因为你听信了某人说“不要用日期类型保存日期”。所以，让我们赶紧关掉这篇文章，把你的数据字典中的char改成date吧。