既然Postgresql支持创建多个schema,schema里面可以创建表、视图、函数、存储过程等,那么如果我不创建新的数据库,就用postgresql自带的Postgres库把所有创建库的需求用创建schema来代替,在schema里面进行建表,查询等很多数据库操作,那这样的话会不会有什么缺陷,这种方案是否可行?
请各位大牛指点。
既然Postgresql支持创建多个schema,schema里面可以创建表、视图、函数、存储过程等,那么如果我不创建新的数据库,就用postgresql自带的Postgres库把所有创建库的需求用创建schema来代替,在schema里面进行建表,查询等很多数据库操作,那这样的话会不会有什么缺陷,这种方案是否可行?
请各位大牛指点。
1 回答1.1k 阅读
1 回答1.1k 阅读
1 回答875 阅读
1 回答662 阅读
我个人认为在大部分应用场景下,题主的想法在我们进行数据库设计时是可行的。但是如果你的应用场景中包含以下需求时,那么你可以优先考虑创建一个新的Database,而不是Schema。
CREATE DATABASE ${数据库名} WITH ENCODING = ${文字编码名} LC_COLLATE = ${字符串排序顺序};
)。如果是同一个Database下的不同Schema,那么在这些Schema中建立的数据表共享相同的规则。如果你希望能够对一组数据库表(或Function等数据库对象)的并发数进行单独控制时,你应该考虑将这组数据库对象放入一个新建的Database,而不是一个Schema中。因为在PostgreSQL中,可以对单个Database的最大并发访问的会话数进行单独控制(通过
CREATE DATABASE ${数据库名} WITH CONNECTION LIMIT = ${最大并发数};
).而Schema只是一个纯逻辑的层次,因此它不具备相应的控制粒度。注1: CREATE DATABASE指定的CONNECTION LIMIT在使用中存在以下限制条件:
注2: CONNECTION LIMIT的定义值如果超过了对postgres实例定义的
max_connections
(定义在postgresql.conf中)时则无意义如果你希望对一组数据库表(或Function等数据库对象)的访问进行严格隔离,而不仅仅是通过SQL层面的PRIVILEDGE来控制。那么你应该考虑将这组数据库对象放入一个新建的Database,而不是一个Schema中。这是因为在PostgreSQL中,对于Access控制,除了SQL级别的权限控制之外,还可以在pg_hba.conf配置文件中进行会话级别的认证控制,基于这种方法,可以对话的以下要素进行高精度的访问控制:
此外,由于会话的最小连接单位是一个Database(在大部分数据库实现中,一个会话的连接目标都是定位于 实例 + 实例中的某个Database). 因此,如果是把一组想要严格隔离的数据库对象定义于另一个Database中,级别对一个数据库角色通过GRANT文赋予了这些数据库对象的访问权限,如果使用这个角色发起的会话没有连接至那些数据库对象所在的Database,在这个会话周期内该角色仍然无法看到那些数据库对象。
综上所述, 由于Schema是一个纯逻辑层面的概念,类似于“命名空间”的概念,因此,确实可以按照题主的说法基于不同的Schema对业务所需的数据库对象进行SQL级别的权限归类。但是,如果数据库设计中对于数据库对象的集合除了基于SQL的权限分类外还有诸如以上的特殊需求时,则应当考虑将这些数据库对象定义在一个新的Database中。