理解模式和表空间.建议稍后分离

Question

DLDR:我

• 确认我对表空间和模式的理解(见图)
• 建议如何组织模式和表空间，使以后的分离变得容易。

背景:在我们的项目中，我们有两个不同的团队正在努力实现一个网站。这个想法是以后将basic-services从website (cms / portal)中分离出来，这样就可以创建不同的网站/门户，这样就可以使用相同的独立basic-services。

当前的安装如下：

TABLESPACE_N  MB  AUTOEXTENSIBLE
FOOBAR_DATA    1024       YES 
FOOBAR_INDEX   1024       YES 
FOOBAR_LOB     1024       YES 
SYSAUX         600       YES 
SYSTEM         700       YES 
TEMP          1024       NO
UNDOTBS1       456       YES 

这个问题是如何将架构移动到另一个表空间。。store indexes in another filesystem的一些建议是有争议的/可疑的。但这不是我问题的范围。我将获得如何组织模式和表空间的建议，以使以后的分离更容易。

确认/澄清:我对神谕的理解如下：

• 表空间:逻辑存储单元，一个或多个数据文件
• Datafiles:符合OS的物理结构，数据文件只能与一个表空间和一个数据库相关联。
• 模式:数据(表、索引)或模式对象(view，..)的逻辑结构的集合，与拥有它的db用户同名，每个用户都拥有一个模式。用户可以被授予对不同用户所拥有的架构对象的访问权限。

在附加的图像中，您可以看到两个模式：

• 白模式S1
• 和黄色模式S2

问题1:

1. 我对如何在数据库中组织架构的理解是否正确？
2. 因此，我们可以创建两个模式(/两个用户)，并以任何我们想要的方式将FOOBAR-services (黄色)和FOOBAR-website (白色)的对象分离开来？
   • 模式1只能与数据文件1和2一起使用表空间1？
   • 模式2只能在数据文件3中使用表空间2吗？

问题2:

您建议采用什么结构使FOOBAR-website和FOOBAR-services以后的分离变得非常容易

• FOOBAR-Web和FOOBAR-Services的不同表空间？
• 每个模式都有自己的表空间(或n个空间)？

Answer 1

我觉得你把事情复杂化了。授权和角色控制用户的访问，而不是数据所在的表空间和数据文件。是的，如果模式有自己的表空间，备份、恢复和导出要容易得多，但这似乎不是您的问题。

• 根据用户/架构分隔业务域。
• 为每个用户/模式提供自己的一组表空间，其中包含表/索引/lobs，例如: User1Data、User1Indexes、User1LOBS
• 创建角色以允许用户/架构访问其他模式中的数据/代码

在你下面的评论中，我想补充如下：

• 用户/架构是分离数据和代码的逻辑方法。从第一天起使用不同的模式，如果您的业务域是这样工作的(这似乎是您所指示的)。可以在部署后将表移动到不同的模式，但这是一项痛苦的工作。
• 在您的注释中，您仍然链接表空间和权限。在用户数据所在的表空间与对该数据授予的权限之间没有链接。

请允许我简化一下：

• 用户和架构允许您通过角色和授权来控制对数据和代码的访问。
• 表空间和数据文件允许您管理数据库使用的物理文件。当每个用户在一组明确定义的表空间中拥有数据时，更容易进行备份和恢复是比较容易的事情之一。