use*_*297 32 database postgresql database-design
我为我的新手问题道歉,但我是PostgreSQl和模式的新手.我很难掌握PostgreSQL中的模式的目的..一般而言.模式的潜在用例有哪些？
我已经说过,模式就像是无法嵌套的目录.好吧,所以我认为模式是一种在数据库中对表进行分组的方法.本书没有说明如何实现,也没有提到除了一个简单的例子(下一段)之外的潜在用途.
福利和潜在用例#1
到目前为止,我只理解了一个(看似微不足道)模式的好处.这个好处是您可以拥有多个具有相同名称的表,并且只要每个这样的表位于不同的模式中,就不会发生冲突,因为名称空间限定符(模式名称)可用于处理所需的特定表.
我真的不明白为什么你会有多个同名的表开头.我认为这是一个非常罕见的案例,但是文档来自我,好像每个人都应该使用模式.拥有多个同名的表对我来说似乎是糟糕的项目管理,并允许这样的不良做法似乎并不值得.最后,你只是允许制造混乱.
我能想到的唯一情况是,你可以在哪些地方进行表名冲突,这是因为你有一个学习SQL的课程,学校的IT管理员希望每个学生能够创建他们喜欢的表格.当然,在我看来,问题是管理员为什么不为每个学生创建1个数据库,而不是每个学生创建1个数据库和1个模式？ Q1:为什么？
哪些其他用例显示了模式的好处？
实施 - 或 - - 的性质
我也对模式的实现/性质感到困惑.
我们假设我们有1个DB,它有3个模式.每个用户1个模式如下:
user1 ='admin' - tableA,tableU,tableJ,tableK,
user2 ='joe '------ tableU,tableJ,
user3 ='kate ----- tableU,tableK.
在上面的例子中,我的目的是让tableU在用户之间共享(在schema joe和schema kate之间).他们不应该获得自己的表的独立副本,他们应该共享对此表的共同访问权限.这种用法对我来说很有意义.用户应该添加/修改/可能删除记录...不添加/修改/删除表.不过我不确定PostgreSQL模式是否可行. Q2:如果我想像上面所描述的那样共享tableU,那么架构joe和schema kate会不会得到自己的表副本,或者我可以指定它们不应该获得自己的副本而只是共享对现有表的访问权限吗？
tableJ是相同的tableK ......除了凯特不能使用tableJ和乔不能使用tableK.根据我对模式的有限理解,这似乎是模式的本质. 问题3:为每个用户制作表副本的目的是什么？这两个表具有相同的结构(列和约束),并且浪费存储空间来为每个用户制作这样的表的独立副本.如果每个用户都拥有自己的每个表副本,我也会认为这将是一场噩梦.我们会抛出像窗口标准化这样的关键概念.这将是一个难以维护的混乱.在我看来,每个用户都应该在公共数据库中添加/修改/删除记录到公共表.
我见过谷歌搜索有关模式的人为每个在线客户为他们的网站制作了一个单独的模式+表格.他们有10万个模式. Q4:我在这里缺少什么？这至少可以说是极端的.他们应该为每个客户添加记录到标准表,而不是为每个客户制作模式和表.这只会增加我的困惑.
无论如何,我希望我已经清楚地说明了我的困惑的关键点.
我正在寻找的是:
(1)通过实际用例示例来清除模式的好处.
(2)清除模式的实现细节.
编辑v.3
潜在的用例#2
如果我正确理解Neville K,他建议作为一个用例:
1个DB,有3个模式.每个用户1个模式(例如,用户名== schema_name):
user1 ='admin' - tableA,tableLogin,tblFin1,tblFin2,tblFin3,tblPrj1,tblPrj2,tblPrj3.
user2 ='joe '------ tableLogin,tblFin1,tblFin2,tblFin3
user3 ='kate ----- tableLogin,tblPrj1,tblPrj2,tblPrj3.
在这里,乔在Fin部门,Kate是项目经理.joe使用的app仅限于Finance相关表,kate使用的应用程序仅限于项目管理表.此限制是通过将用户名绑定到与搜索路径绑定的模式(在DB级别强制执行)来实施的.
问题5:如果没有架构,是否会有相同的限制？哪些应用程序可用于哪些表是应用程序在开发团队提交应用程序时设置的表的功能.没有？或者我们假设我们正在使用您指向数据库的现成应用程序,我们担心应用程序无法在其设置中限制为某些表(并且此限制已锁定在现成的密码中应用)？
潜在用例#3
如果我正确地理解了Catcall,他建议作为一个用例:
您希望将托管在1个物理系统上的数据库服务器的服务租赁/租赁给需要数据库服务的多个客户的方案.因此,出现了类似多租户的情况.此时,您可以选择:
(1)为每个租户(客户)建立一个单独的数据库
- 更安全,更方便,但每个系统可以支持更少的租户.
(2)一个共享数据库,每个租户(客户)
都有一个模式 - 安全性低,不太方便,但每个系统可以支持更多租户.
潜在的用例#4
如果我正确理解Scott Marlowe和Catcall,另一个用例是:
在开发过程中使用模式隔离开发人员的新内容.稍后可以将工作合并到另一个模式.
Mik*_*ll' 18
我见过谷歌搜索有关模式的人为每个在线客户为他们的网站制作了一个单独的模式+表格.他们有10万个模式.Q3:我在这里错过了什么？这至少可以说是极端的.他们应该为每个客户添加记录到标准表,而不是为每个客户制作模式和表.
每个租户(客户)一个数据库易于构建,它为您提供最大的租户隔离和最简单的灾难恢复.但它相对昂贵.
每个租户一个架构也很容易构建.租户之间的隔离程度较小.dbms可以为每个服务器支持更多租户,每个租户使用一个模式,而每个租户使用一个数据库.一个租户的灾难恢复比每个租户一个数据库更复杂.
共享模式要求每一行都有一个租户标识符.硬件和备份更便宜; 一个租户的灾难恢复可能是一个真正的婊子.(要恢复单个租户的数据,您必须在每个表中恢复一些行.当发生这种情况时,性能会受到所有租户的影响.)隔离比较棘手.由于租户共享表,确保没有租户可以访问其他租户数据比使用一个数据库或每个租户一个模式要困难得多.
这个东西的搜索词是"多租户数据库设计".所以也有一个多租户标签.
另一个常见用途是将属于一起的数据库对象分组.例如,如果你正在开发一个会计数据库,实现了所有对象"应付账款"功能可能会走在"AP"架构.我也使用模式进行PostgreSQL扩展.在我的数据库中,我在"hst"模式中安装了hstore扩展,在"tbf"模式中安装了tablefunc扩展,等等.
这是我见过的另一种常见用法.模式并search_path允许两个或更多开发人员在不需要自己的副本的情况下处理大型数据库的同一个副本,但不会相互影响.
假设Joe正在撰写评论表,Jim正在研究工作流程表.他们都需要用户,组等表.Joe创建了一个模式,创建了自己的注释表工作版本,并且可以随意使用它:
create schema joe;
create table joe.comments (rest of new tabledef here);
set search_path='joe','public';
现在,当Joe alter table在joe.comments桌面上工作时,Jim看不到任何变化,他的开发不会受到破joe.comments桌等的影响.当Joe的代码有一个search_path的'joe','public'运行时,它会看到joe的注释表,而其他人都看到原始的.
经过彻底的测试,Joe的评论表基本上可以一举代替原版,而不会中断Jim的开发.这次乘以40个开发人员,它允许所有40个人在相同的dev db上工作,而不会相互吹嘘(或者至少不那么频繁).
小智 7
内维尔K的回答捕捉到了本质,但也许有点简短.
模式本质上是命名空间.它们在命名空间在编程中有用的相同情况下很有用:你有许多东西,很多你想要将它们分成不同的子集合(很多 - 但是少于(比如说)10,000个这样的子集合集合,只要有一个级别),同时能够在它们之间互操作.使用模式可以为其他数据库对象提供更"自然"的命名标准.
另外,命名空间的价值也不受新程序员的欢迎.事实证明,允许多个对象具有相同名称这看似微不足道的好处并非如此微不足道.只有当一个人在大型项目上工作了一段时间(有数千个"代码对象":表,视图,索引,存储过程,域等)时,人们就会明白命名空间的好处超过了它们的成本.
在较早的时代(而不是PostgreSQL),我在一个拥有大约20个客户的计算机局工作,从DBMS的250个并发用户到一个,每个通过私人租用的电话线.(这是在互联网之前.)每个客户都有自己的架构,管理员用户(角色)可以在员工来去时创建和删除其他用户,授予和撤销权限,并执行有限的数据定义工作和以自己的架构导入/导出.作为开发人员,我不得不使用模式,因为只有一个DBMS实例和一个数据库.所以...如果上述内容不具说服力,你可以说模式符合SQL标准(由于历史原因),因此PostgreSQL支持模式.
今天,在实验室环境中可能会出现与我的情况类似的情况,其中一些研究人员(或数百名学生)每个人都希望在访问公共模式中的公共集合时处理他们自己的数据.使用模式有助于阻止事故:无意中践踏对方的数据.
模式的主要好处是为数据库表提供逻辑分组。最可能的用例是：
| 归档时间： |
|
| 查看次数： |
9021 次 |
| 最近记录： |