如果五个应用程序使用相同的数据库，并且这些应用程序需要在不同时间发布，那么哪种类型的体系结构或配置适应该场景？
主要关注点是：允许五个应用程序中的任何一个更改数据库，然后可以破坏生产中的四个应用程序中的任何一个。
答案 0 :(得分：4)
亚马逊的首席技术官Werner Vogel says，服务应该是独立的，独立的，并且在面向服务的体系结构中拥有自己的数据。
也许另一种方法是将应用程序的共享部分公开为拥有其数据的服务。让需要该信息的应用程序从一个地方获取。
这种安排可以为您提供一个应用与该数据相关的规则的地方。在一个地方更改它们，所有客户一次看到它们。
我与几个共享数据的应用程序存在的一个问题是，应用程序可能会将不同的业务规则应用于相同的数据。
也许您可以使用视图和存储过程的组合隐藏架构详细信息。这将使公共数据层保持在数据库中，在这里，所有应用程序都可以更容易地维护在一个位置。缺点是你将使用其存储的proc语言绑定到单个数据库，但这并不是太严重。大多数地方不会轻易切换数据库。中间层代码来来往往，但数据依然存在。
答案 1 :(得分：1)
对最低级别的数据进行清理通常意味着执行一些参照完整性以及主要和外部关键作业。这必须在存储过程中完成（这样存储过程应该知道序列/生成器A_seq中的值应该放入表A的主键中，并且这也应该放入表A中的A_id中等）。可以有一些名为SavePurchaseHead，SavePurchaseDetails，GetSegmentForCustomer，GetCustomerBalance，GetOverdueLevelForSegment等的存储过程。这主要是为了隐藏数据库中INSERT，UPDATE或JOIN sql指令的逻辑。
现在想象一下，您想要提供一些商业知识，例如“客户逾期5000美元在他用现金支付之前无法进行新购买”？存储过程通常不适合进行此类计算 - 更好的解决方案是使用MakeNewPurchase等业务服务，这将获取客户数据和购买数据，以及执行业务。此服务可能首先获取有关客户群的信息，而不是获取客户余额并将其与此段过期级别进行比较。如果一切正常，将执行SavePurchaseHead和SavePurchaseDetails等程序。
因此，您将拥有一定程度的知识：客户端应用程序将只知道购买需要您调用服务MakeNewPurchase。他们会用“商业语言”说话。此外 - 必须在一个地方（业务逻辑层）而不是五个应用程序中进行业务逻辑的重要更改。与业务逻辑层相比，业务逻辑层将了解业务的制定方式，但缺乏有关如何组成UI的知识，并且缺乏有关如何存储和优化数据的知识。数据库将只具有关于数据及其存储方式的知识。这将在所有层之间划分责任，并且在工作时我是多开发人员团队，它将通过微小的界面帮助您维护一些订单。并且 - 如前所述 - 一个应用程序不会通过“破坏”数据而伤害其他应用程序。
最后两件事 - 当我说“面向服务的中间件”时，我并不是说任何炒作。正如我之前写的那样 - SELECT和UPDATE应该在DB级别上。 “中间件”或“业务层”（无论您如何称呼它）应该是更加面向业务的术语。实际上，Web服务和WCF只是一种工具。无论你怎么做 - 都可以用WCF，J2EE，PHP，WS- *，Borland Delphi甚至纯C来完成。你将使用哪种技术考虑可用的开发人员，技术的学习曲线，可扩展性和你的其他需求。但我认为必须通过一些网络来完成，而业务层应该靠近数据库。
我希望这也涵盖了您最后一次考虑如果数据库发生变化需要对您的五个应用做些什么。看 - 需要更改数据库应该来自业务需求。如果您需要存储一些其他信息 - 您将重新设计它的业务服务，并可能向DB添加一些字段。您必须更改数据库和业务服务。如果您巧妙地设计业务层，那么您很可能无需修改五个应用程序。例如，假设您想要计算客户评分并在内部使用它来为您的最佳客户计算好报价 - 在这种情况下，您最有可能将一个字段添加到DB并更改某些服务（添加服务以计算评分和更改报价计算服务）无需更改GUI。但是，如果有一天你会得出结论，客户姓名和地址太少，而你想收集他所有的教育，健康，家庭，婚姻，刑事和信用记录 - 你不仅需要改变DB，还要更改业务层，并为您的五个应用程序的用户提供十几个新的输入屏幕来收集此类数据...
答案 2 :(得分：0)
这实际上取决于“更改数据库”的含义。如果您的应用程序可以在运行时更改数据库（例如，通过允许客户定义自定义实体/属性以及创建/更改表来存储这些属性），您只需要“命名”所有自定义（例如，在运行时可更改）数据库对象每个申请。但是，为了提供明确的升级路径，您无论如何都必须这样做。
如果，OTOH，你的意思是“应用程序＃5的第2版现在正在开发中，它需要新的数据库结构，打破现在生产中＃1到＃4的应用程序”，答案是“你不能 - 而且不应该”做它“。您的数据库更改应该是纯增量的。在所有应用程序之间共享一个共同的“API”层可能是有意义的，它们提供了数据库中所有需要的通用功能，并在其上使用API版本。
答案 3 :(得分：0)
您的关注点涉及设计此系统的主要目标。如果需要为多个客户端提供对一个数据库的访问权限，则需要存在某种类型的共享数据层。
您没有指定这是Web应用程序还是可安装客户端，但类似的方法对两者都适用。在前一种情况下，MVC模式将做你想要的。您只需将您的应用程序视为使用相同模型的视图和控件集。对于单独的客户端应用程序，相同的方法可行，但您还需要考虑使用Web服务或其他一些rpc技术来获取数据。这样，仍然有一个管理访问的公共数据层。
答案 4 :(得分：0)
任何问题都可以通过添加一个额外的间接层来解决（除了太多层的问题）
每个应用程序都会通过它自己的视图/存储过程与数据库通信，只要它们仍然可用，然后应用程序就可以了。 （这也可以作为代码中的DAL层实现）
这样，如果您需要对数据库进行更改，则只需要进行一处更改。
话虽如此，我不会将其作为单个数据库实现。每个应用程序都拥有自己的数据，并拥有自己的数据库。
如果一个应用程序需要来自其他应用程序的数据，则有3种方法可以执行此操作：
这将使得哪个应用程序拥有哪些数据非常清楚。
答案 5 :(得分：0)
使用
隔离您的数据数据库中的存储过程 提供基本控制 参照完整性
面向服务的中间件 提供有关BUSSINES使用的控制 数据
并提供一些智能运行时版本控制，因此过时版本的客户端应用程序的用户将收到有关使用好消息框而不仅仅是错误消息进行升级的通知。
答案 6 :(得分：0)
随着时间的推移，每个应用程序都会尝试将数据库拉向不同的方向。最安全的做法是将其分成几个数据库，然后以某种方式处理数据复制。但是，这有其自身的问题，特别是如果所有数据库需要立即同步而不是最终同步。
我还没有听到有经验的DB告诉我他们更喜欢多个数据库。