Question

在开发多区域应用程序时，在数据库设计方面，处理诸如货币差异，工作日和时差等问题的最佳做法是什么。

您是否为每个不同的地区/国家/地区创建单独的数据库？
是否有一个不受国家或地区特性影响的公共表的数据库，然后为每个特殊区域创建单独的数据库？
将它们全部放在一个数据库中，并拥有关系父子引用，例如“国家/地区”表，“货币表”，“费用表”等。

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

我可能会对我的问题稍微提出一些问题，但我希望其内容足够清晰。

Answer 1

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

E.g：

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日的价格在Jp售出2643日元，然后将价格上涨至2810日元。

几点警告

我已经使用ISO代码来获取国家和金钱。这应该是足够强大，以避免将来出现问题。为了上帝的爱不要使用特定于应用程序的代码来处理状态或状态货币。即使你正在设计它的一小部分世界，像，dunno ...＆＃34;德语国家＆＃34; （德国，奥地利，瑞士的一部分）抵制使用像这样的东西的诱惑 GER / AUS / SWI或任何非标准的。
管理时区非常毛茸茸。我把它放在与国家相同的表中只是为了说明应该将哪种数据与国家/地区条目相关联，但实际上一些国家/地区跨越多个时区（ru，us），因此您可能需要更复杂的模式。
在上述第（2）点之上，如果您的应用程序确实存在于单实例数据库中，则必须确定一条规则，说明如何向用户显示时间并坚持使用。一致。见下文。

世界范围内的应用程序存在的问题是，您可能在班加罗尔有一台服务器，用户位于罗马。所以你基本上有两个选择 - 要么将每个操作的时间戳加上实际服务器所在的时区＆＃34;并让用户在心理上调整差异，或者您仍然使用特定时区为所有内容添加时间戳（当然，您可以使用UTC而不是本地时间，这也适用于其他方法）并自动将其转换为本地用户显示时区。

所以你可能会有类似于＆＃34;记录创建于UTC 12-MAY-2014 00：34＆＃34;存储在您的数据库中并显示我＆＃34;记录创建于2014年5月12日01:34 MET＆＃34;因为我正在使用你在意大利的申请。

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

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

如何为应用程序设计数据库以处理多个国家/地区的需求

1 个答案: