1

在开发多区域应用程序时，在数据库设计方面，处理货币差异、工作日和时间差异等问题的最佳实践是什么？

  • 您是否为每个不同的地区/国家创建单独的数据库？
  • 有一个不受国家或地区特性影响的公用表的数据库，然后为每个特殊地区创建单独的数据库？
  • 将它们全部放在一个数据库中，并具有关系父子引用，例如 Country 表、Currencies 表、Charges 表等。

还有一个工作日的问题，几乎每个国家和每年都会有所不同。假设代理商将在每个工作日收取罚款，因为他们没有银行收款，因为每个国家/地区都不同，在设计数据库时如何处理这个问题。

我可能有点混淆了我的问题，但我希望本质足够清楚。

4

1 回答 1

5

除非您有其他要求（例如可扩展性/冗余），否则最好的方法是将所有内容保存在单个数据库实例中，定义一个收集您感兴趣的所有国家/地区的表（以及它们特定于国家/地区的属性）。

例如：

Country-cd |Country-Name | Currency | Language | Time-zone | Region-cd
     it      Italy           EUR         IT        MET         EMEA
     ...     ...             ...         ...       ...         ...
     jp      Japan           JPY         jp        JST         Far-East

然后使用国家代码作为可能具有特定国家内容的其他表的键的一部分......比如价格：

 Item-id  | Country-cd  | Valid-from  | Valid-to    | Amount x unit
 950595   |    IT       | 03-MAY-2013 |  31-DEC-2099|    23.56 
 950595   |    JP       | 01-FEB-2013 |  12-AUG-2013|  2643.00
 950595   |    JP       | 13-AUG-2013 |  31-DEC-2099|  2810.00

因此，同款商品在意大利售价为 23.56 欧元，而在 2 月 1 日至 8 月 12 日期间，它将以 2643 日元的价格在日本出售，然后价格将上涨至 2810 日元。

几个警告

  1. 我使用了国家和货币的 ISO 代码。这应该足够强大以避免将来出现问题。为了上帝的爱，请勿将特定于应用程序的代码用于状态或货币等内容。即使你是为世界的一小部分设计它，比如，不知道......“德语国家”（德国、奥地利、瑞士的一部分）抵制使用 GER/AUS/SWI 之类的东西或任何其他东西的诱惑不标准。
  2. 时区管理起来非常麻烦。我把它和国家放在同一张表中只是为了说明什么样的数据应该与国家条目相关联，但实际上有些国家跨越多个时区（俄罗斯、美国），因此您可能需要一个更复杂的模式。
  3. 在上面的第 (2) 点之上，如果您的应用程序真的存在于单实例数据库中，您必须确定如何向用户显示时间的规则并坚持下去。始终如一。见下文。

跨世界应用程序的问题在于，您可能在班加罗尔拥有一台服务器，而用户在罗马。因此，您基本上有两种选择-您可以使用实际服务器“驻留”的时区为每个操作添加时间戳，并让用户根据差异进行心理调整，或者您仍然使用特定时区为所有操作添加时间戳（您当然可以使用UTC 而不是本地时间，这也适用于其他方法）并在显示时自动将其转换为用户本地时区。

因此，您的数据库中可能会存储“在 UTC 2014 年 5 月 12 日 00:34 创建的记录”之类的内容，并向我显示“记录是在 2014 年 5 月 12 日 01:34 MET 创建的”，因为我正在使用您来自意大利的应用程序.

（这将证明对用户来说更容易，特别是如果应用程序允许他们创建带有时间作为输入的条目 - 例如预订会议室 - 但在开发方面会花费您更多，并且可能会变得有点复杂管理当可以从不同的时区更新相同的记录时）。

这些是基础知识，真的……当然，您还必须阅读有关I18N的内容，并决定是否希望错误消息和 UI 标签是多语言的。I18N 主要关心这一点（即如何管理不同语言的输入和输出），但它也为更深奥的东西提供了指导，比如文化上的图标，所以我建议对它做一些研究。

于 2013-02-21T14:27:30.593 回答