我所说的多站点系统是指具有多个相同版本窗格的系统。Gamespot 就是一个例子，它会根据您在 uk.gamespot、us.gamespot 等网站上显示不同的发布日期甚至是不同的游戏。
选址在这里不是这个问题。问题在于开发的过程和易用性，以及如何选择或输入特定于站点的数据。各种系统组件也有可能不需要特定于站点，并且在极少数情况下，需要所有站点的所有数据都是可见的和可选择的，以用于报告和管理目的。
已经考虑了以下技术，尽管我们知道它们会起作用，但我们对它们实现的繁琐性质感到不满：
表视图 - 通过在每个表上为每个站点创建多个视图，我们可以加载特定于站点的要查询的数据。但是，内联 SQL 必须动态调用正确的视图，并且在创建新站点的情况下，必须创建一整套新视图。
SQL 修改 - 通过创建 SQL 中介函数，可以修改 SQL 以更改 where 子句并连接到仅选择特定于站点的数据的目标列。但是，我们认为通过这样的设备运行我们所有的查询可能会在未来出现严重问题，并且可能会限制我们查询的灵活性。
内联站点子句 - 尽管这是最麻烦和最烦人的实现，但如果我们能够在我们的编码方式上执行标准，它将被证明是最可靠的。尽管这可能是最可靠的，但对我们的开发人员来说也是最不吸引人的，这意味着为几乎每一个查询编写站点子句。
因此，与其寻找在系统的更高级别上实施该系统的最佳方法，我们正在尝试找到一种方法，该方法将允许在基础级别上相当简单地实施特定于站点的数据选择。
如果这个问题在任何方面都过于宽泛，请告诉我，我会尝试进一步缩小范围。
第一次编辑：
就表格而言，跨站点的数据类型是相同的。用户表将在所有站点之间共享，并且每个用户只能访问一个、部分或所有站点。
让我们更进一步地看 Gamespot 的例子。一位用户负责管理英国版本。
有关游戏及其评论的信息来自所有站点均可访问的记录，因为这是全球相关信息。但是，假设发布日期来自另一个特定于站点的表。以典型方式检索有关游戏的信息，但是获取发布日期需要一些额外的代码才能为正确的站点获取正确的信息。
关于用户，无论用户当前管理的哪个站点，都应该是选择和插入的目标站点。
可以想象，发布日期不是核心表，每个日期不能简单地直接映射到其各自的游戏。
（我并不暗示对 Gamespot 的运作有任何了解，这个例子是假设的）