在我需要使用整个日期（即日，月，年）作为一个整体的场景中，并且永远不需要在我的数据库中提取日期，月份或年份部分应用程序，最佳实践是什么：
编辑： - 问题可以概括为：
在可能的情况下制作复合属性是一个好习惯，即使我们只需要处理整个属性吗？
答案 0 :(得分：1)
实际上，具体问题和一般问题有很大不同，因为具体问题涉及日期。
对于日期，组件元素并不是您正在建模的事物的一部分 - 历史上的一天 - 它们是您正在建模的事物的表示的一部分 - 您（以及您所在国家/地区的大多数人）使用的日历中的日子。
对于日期，我会说最好将它存储在单个日期类型字段中。
对于广义问题，我通常会将它们分开存储。如果你完全确定你只需要处理它作为一个整体，那么你可以使用一个字段。如果您认为有可能需要拉出一个组件以供单独使用（即使只是用于验证），那么请单独存储它们。
特别是日期，绝大多数现代数据库有效地存储和操作日期作为单个日期值。即使在您想要访问我建议使用单个日期字段的日期的各个组件的情况下。
你几乎不可避免地需要最终进行某种日期算术，并且大多数数据库系统和编程语言都提供了某种操作日期的功能。使用单个日期变量可以更容易地使用它们。
对于日期，整个复合日期标识您正在识别的主要现实世界。
日/月/年是该单一事物的属性，但仅限于描述它的特定方式 - 西方日历。
然而，同一天可以用许多不同的方式表示 - unix时代，格里高利历，农历，在一些日历中，我们处于一个完全不同的年份。所有这些表示都可以是不同的，但是指的是同一个人的现实世界。
因此，从建模的角度来看，从数据库/程序效率的角度来看，对于日期，请尽可能将它们存储在单个字段中。
对于概括，这是一个不同的问题。
根据经验，我将它们存储为单独的组件。如果你真的确定你永远不想访问组件信息，那么是的，一个字段就可以了。只要你是对的。但是，如果甚至有能力打破信息，我会将它们从一开始就分开。
将字段连接起来要比将字段与组件字符串分开要容易得多。这既是从程序/算法的角度来看，也是从计算资源的角度来看。
我在编程中遇到的一些最痛苦的问题是尝试将单个字段分解为组件元素。它们最初是作为一个元素存储的，当业务发生变化以至于意识到它们需要组件时......它已成为一个相当大的挑战。
大多数复合数据项与日期不同。如果日期是单个项目，有时（通常在西方世界）由日 - 月 - 年复合体表示，大多数复合数据元素实际上代表几个具体项目，并且只有这些项目的组合才能真正唯一地表示特别的事。
例如银行帐号（无论如何在新西兰）有点像这样：
这些元素中的每一个都代表一个真实世界的东西，但它们共同识别我的帐户。
您可以将它们存储为单个字段，并且它在很大程度上有效。您可能决定使用连字符分隔元素，以备不时之需。
如果您真的不需要访问该信息的特定部分，那么您可以将其存储为复合材料。
但如果在赛道上落后3年，一家银行决定收取更高的费率，或者需要不同的处理;或者如果您想进行区域促销并且可以在分支号码上键入，现在您有不同的挑战，并且您需要提取该信息。我们选择连字符作为分隔符，因此您必须将每一行解析为组件元素才能找到它们。 （这些天磁盘相当便宜，所以如果你这样做，你会存储它们。在过去，它很昂贵所以你必须决定是否付钱存储它，或者每次付费重新计算它）。
就个人而言，在银行账户案例中（可能是我能想到的大多数其他例子）我会单独存储它们，并且可能设置参考表以允许验证发生（例如，您无法输入我们不知道的银行。）