标签: schema

几年过去了……但我遇到了一个问题集，它让我想起了模式设计模式，我正在努力回忆细节。

本质上，该模式由一个为所有插入、更新和删除提供服务的3 NF（或其他）数据库组成。在某些定期或事件驱动的基础上，它会将其全部（或部分）状态发布到另一个针对高性能只读访问进行了优化的数据库。本质上，发布通常针对完全不同或非规范化的模式。

问题是……这是众所周知的模式吗？如果是，它叫什么，除了相同状态的重复存储之外还有什么陷阱。

我们正在构建一个实时银行平台和应用程序。

我们主要关注的是跨多个数据库服务器的数据的安全性和一致性。我们需要事务，我们不能承受断电和丢失数据的风险（我说的是 MongoDB）。我们的次要关注是架构 - 为我们的应用程序租户用户提供的功能。

我们还想避开大型数据库上的模式更新地狱。我们租户的自定义架构是可选的，但非常可取。

我们是非常重的 AJAX 前端，我们的后端是完整的 nodejs。我们做了很多 JSON 数据处理。

我们应该使用 MySQL 吗？对于我们的案例，是否有任何 noSQL 解决方案（也许是 CouchDB？）？

感谢您抽出宝贵时间回答这个问题！

我有一个中等大小的数据库（约 100 个表），它使用 GUID 作为所有表中的主键。

在我们最活跃的表之一中，GUID 导致存储需求不必要的增加。该表本质上是一个主键 (GUID)、4 个外键 (GUID) 和两个datetime字段。

我想将主键和所有外键更改为整数，从而将表降低到当前大小的三分之一左右。系统中还没有大量数据，因此转换现有数据应该不是一个大问题。

我的主要问题是，最好的方法是什么？

1. 将所有引用的表（以及我数据库中的大多数表）转换为使用整数键。

2. 向每个引用表添加额外的自动增量整数标识以用作外键，并维护这些表中的 GUID 以供外部引用（通过 API 等使用）。

我正在创建一个表来存储有关对象在网格（游戏地图）中的位置的信息。

例如，我有一个 10x10 的网格，我想在数据库中存储单元格 (5,5) 有一个蓝色框，(3,3) 有一把红色椅子等等。

任何一个方格中可以有多个项目，但同一个项目不应该在同一个方格中出现两次。

这种结构可以接受吗？（主键中的所有列）

 (room_id (FK), room_object_id (FK), x_cell, y_cell)(PK)

还是有这个会更好

id(PK), room_id (FK), room_object_id (FK), x_cell, y_cell

我认为第一种方法更有意义，但我担心在输入内容时增加完整性检查可能会产生大量不必要的开销。

假设您有一个装满小部件的仓库。仓库中的每个小部件都存储在仓库内的特定可识别位置。您可能有一个如下所示的架构：

小部件也可以（可选）位于仓库中的购物车上，这可能会导致这样的模式：

但是，出现了一个问题，因为购物车也只能位于仓库内的一个位置，这将先前的模式变成了这样：

但是，此模式是非规范化的，可能会导致异常，例如数据是：

widgetID storageLocationID 购物车ID
================================
1 foo
2 巴

尽管两个小部件位于同一个购物车上，但数据库将它们显示在不同的位置，这是不可能的。

如果需要购物车，通过简单地从Widgets表中删除storageLocationID来解决这个标准化问题会相对简单。但是，由于不需要购物车，该解决方案将不起作用。