【问题标题】:Designing a common database for multiple, unique apps为多个独特的应用程序设计一个通用数据库
【发布时间】:2018-09-14 15:08:50
【问题描述】:

我是数据库世界的新手,所以如果我没有使用正确的词汇,请提前道歉。

我正在研究在线和离线使用的云托管应用商店的设计注意事项。某些应用程序将依赖相同的信息,例如人员信息。

  1. 最好先创建包含所有公共信息的数据库,然后让应用程序使用这个公共数据库?
  2. 如果有一个应用程序需要但另一个应用程序不需要的唯一字段,有没有办法只下载所需的字段(以节省内存和数据计划的使用)?
  3. 假设某些(但不是大多数)应用程序需要近乎瞬时的访问速度,那么它们是否应该拥有具有相同信息的独立、唯一数据库?

对于进一步阅读该主题的任何建议,我也将不胜感激。谢谢!

【问题讨论】:

    标签: database


    【解决方案1】:
    1. 如果您清楚了解什么是常见的并且将保持常见,那么最好先设计它。但是从一开始就准确地知道它是很难的,所以要保守一点。

    2. 数据库不是关于下载的,而是(主要)关于查询和更新的。你当然可以只查询你需要的行和字段,然后只转移它们。

    3. 拥有单独的数据库可能会提高速度。但是,使查询高效的正确设计通常更重要。此外,您总是在带宽方面的预加载和访问速度之间以及在内存消耗方面的缓存/复制和访问速度之间存在冲突。

    为了我们更好地回答您的问题,请说明您really解决了什么问题。这样做,以及对数据库进行一些背景阅读,将帮助您更好地提出您的问题。

    【讨论】:

    • 谢谢!不幸的是,问题是我不知道我真正解决了什么问题。现在,组织中有一些混乱,有成千上万的独特或冗余的应用程序/软件程序,它们在性质上与您的 Google 应用程序商店一样多样化。高层表示他们希望将它们全部迁移到云端。在没有了解所有这些程序的情况下,我首先尝试就可能是最好的通用(但不是唯一可用的)方法制定更高级别的指导。
    • 我会专注于找出和制定正确的问题,并与正确的利益相关者一起审查我的理解。在此之前,我会尽量不为该项目编写任何代码。比无所作为更糟糕的一件事是把时间和金钱花在解决错误或不存在的问题上。
    猜你喜欢
    • 1970-01-01
    • 2020-01-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-08
    • 2014-12-05
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多