我有一个具有许多其他应用程序和用户的“传统”DB2数据库。尝试尝试使用Rails应用程序。通过ibm_db驱动程序获得了一切工作良好。具有DB2和多个架构的Rails
问题是我有一些表，如schema1.products，schema1.sales和其他表，如schema2.employees和schema2.payroll。
在ibm_db适配器连接中，我指定了一个模式，如schema1或schema2，并且我可以在该模式中工作，但我需要能够基本上可互换地轻松（并透明地）引用这两个模式。我不想破坏其他应用程序，而我通常针对DB2编写的SQL没有任何这些限制（可以将SQL中针对DB2的模式混合起来，而不会有任何问题）。
我想仅指定表名作为“schema1.products”，例如，并用它来完成，但似乎并没有采用“rails方式”去实现它。
对此提出建议？
架构在DB2是一个非常方便的方式来提供不同的命名空间，以不同的应用。例如，您可以将名为“招聘”的应用程序的所有数据库对象从称为“工资单”的说明应用程序中分离出来。您可以让具有相同名称的对象（表，视图，过程等）驻留在多个模式中，而不会彼此混淆。让你的应用程序设置一个模式是一个方便的方式，它说：“嘿，我是一个工资单，我只想用我的对象”。那么，当你想使用另一个应用程序拥有的对象时会发生什么？那么，在传统的程序编程语言中，应用程序代码会在引用另一个模式中的对象时明确指定模式，或者您只需执行SET CURRENT SCHEMA即可切换到另一模式。 Ruby on Rails中的ActiveRecord等ORM的问题在于，您不应该使用SQL，即在引用对象时没有很好的“Rails方式”来指定模式。您可以使用find_by_sql并在SQL语句中限定对象，但这不是RoR人员认为的良好Rails。 您可以修复DB2端的问题。您可以在“外部”模式中为每个表定义一个视图，但是您必须小心地命名该视图，以便它不会与您的主模式中已有的视图相冲突。而且，当你这样做时，你无疑会创建不是真正的Rails名称的名称。 Rails人非常自豪的“Rails方式”。它使创建新应用程序变得非常简单。 Rails在这个领域真的很棒。但是，当涉及到Rails已经存在的内容时......我们怎么说呢......糟透了。如果你想使用现有的数据库结构，我建议你必须接受做不是Rails Way最好的例子。
嗯，不是我期待的，但我想这就是关键。这似乎迄今为止工作得很好，尽管为了不同的模式而建立新的数据库连接看起来有点矫枉过正。但如果这是“铁轨方式”，那么我只需要习惯它。幸运的是，我只有两个模式来处理，所以这应该工作得很好。 非常感谢！ – GNUMatrix 2010-04-08 19:21:20
如果您想要创建从一个数据库到另一个数据库的视图，但是这首先破坏了它们的目的 – Will 2010-04-08 19:34:49
在DB2本身中，我也可以使用别名，只是有点繁琐的设置，特别是如果任何表名称重复从一个架构到另一个架构。让我感觉到的是，这些都在同一个数据库中。模式基本上用作正式表前缀，而不是任何东西。我的猜测是，在其他数据库中，它们可能有更根本的目的，但在DB2中并不那么重要。 我试图坚持使用rails惯例，尽量避免这种情况，因为这样会导致很多麻烦，所以这种多个数据库连接的事情现在必须要做。 – GNUMatrix 2010-04-08 23:48:06
（意见篇！）这是我对Rails总体印象的总体印象......我想我对自己想要完成的事情有相当好的把握，同样重要的是，为什么，以及何时启动新项目倾向于真正同意他们。然而，试图与可能来自其他地方的任何事物结合起来是非常可怕的。仅仅想到在生产数据库上运行rake并不完全是从rails底部开始制作的，这真是令人恐惧。我不断回来，虽然他们有进步和东西确实得到修复。 – GNUMatrix 2010-12-05 19:24:06