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

Nap*_*eon 1 architecture database-design

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

  • 您是否为每个不同的地区/国家/地区创建单独的数据库?
  • 有一个不受国家或地区特性影响的公共表的数据库,然后为每个特殊区域创建单独的数据库?
  • 将它们全部放在一个数据库中,并有关系父子引用,比如说"国家"表,然后是"货币表","收费表"等.

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

我可能把我的问题弄得有些混乱,但我希望这个问题很清楚.

p.m*_*ino 5

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

例如:

Country-cd |Country-Name | Currency | Language | Time-zone | Region-cd
     it      Italy           EUR         IT        MET         EMEA
     ...     ...             ...         ...       ...         ...
     jp      Japan           JPY         jp        JST         Far-East
Run Code Online (Sandbox Code Playgroud)

然后使用国家/地区代码作为每个其他表的密钥的一部分,这些表可能具有特定于国家/地区的内容...例如价格:

 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
Run Code Online (Sandbox Code Playgroud)

因此同样的商品在意大利的售价为23.56欧元,相反,它将从2月1日到8月12日以每日264日元的价格售出,然后将价格提高到2810日元.

几点警告

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

世界各地应用程序的问题在于您可能在班加罗尔拥有一台服务器,其中包含罗马的用户.因此,您基本上有两种选择 - 您可以将每个操作的时间戳与实际服务器"所在的时区"进行时间戳,并让用户在心理上调整差异,或者您仍然使用特定时区为所有内容添加时间戳(当然可以使用UTC而不是本地时间,这也适用于其他方法)并在显示时自动将其转换为用户本地时区.

所以你可能会在你的数据库中存储类似"在UTC 12-MAY-2014 00:34创建的记录"并向我显示"记录创建于2014年5月12日01:34 MET",因为我正在使用您在意大利的应用程序.

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

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