这期内容当中小编将会给大家带来有关如何用MYSQL或者甲骨文的方法管理POSTGRESQL,,文章内容丰富且以专业的角度为大家分析和叙述,阅读完这篇文章希望大家可以有所收获。
写这篇文字的起因是众多的DB们投入到学习PG数据库,遇到了一些困难,其实提出这个题目的时候,其实我也在想,每种数据库都有自己的适合的管理方法,有些是管理方法实则是无奈。最近有人问POSTGRESQL使用的方式是更贴近甲骨文,还是MYSQL。
为什么会提出这样一个话题,
1使用PG前,提出问题的人使用的或管理的数据库已经深入骨髓,很愿意用原来的管理方法来管理新的数据库,这是很正常的事情,我们都愿意用已有的经验去套用在新的事务上,加快对新事物的理解和使用。
2低估了新事物与原有经验的之间的冲突,如同比如去了国外做公交车,如果你不按停止的按钮,公交车是到站不停的,而国内这样的情况是不会出现的,更有意思的是,如果你按错了按钮,也是要下车的,因为不好意思,别问我怎么知道的。
所以今天的题目还算有点意思,有点讨论性,将三个数据以及使用者的经验来一个混合本来就是挺有意思的话题。
1,甲骨文中没有数据库的概念(类似MYSQL SQL SERVER),甲骨文中是有模式的概念的,在甲骨文的世界中可以看做一个模式就是一个数据库。
2,在MYSQL中是没有模式的概念的,他是通过不同的数据库来分割逻辑,或物理上的数据信息。
3,类似POSTGRESQL和SQL SERVER这样的数据库就属于比较,怎么都行的,这两者既有模式的概念,也有数据库的概念。你想用任何的方式来分割都是OK的。但SQL SERVER历史原因,习惯使用数据库来分割的是常见的。
说到这里问题是PG怎么办,PG中的模式和ORACLE概念无差,而不幸的是,他的数据库的概念也和MYSQL无差。貌似PG属于脚踩两只船的那位。
那我们在使用PG的时候是更倾向于将所有的表都塞到一个数据库里面,然后用模式+用户+权限的方式来管理好。
还是使用MYSQL或SQL SERVER那种创建多个数据库在一个实例的方式,每个数据库有不同的用户的方式来管理,更符合PG的性格。
如果我们以甲骨文的方式管理PG,在一个数据库里面创建多个模式,也就是放弃PG的多数据库的概念,仅仅使用一个数据库,我们会遇到另一个问题,autovacuum工人,根据下面的一段官方的文字
经过推敲清理线程是一个个数据库来进行清理的,那如果将所有的表都塞入到一个数据库,那我是否能推断出,即使设置了多个作品一个数据库也只能使用一个清理线程(如果这样理解有误,请告知谢谢)。
这就引出另一个不同的概念,在甲骨文有UNDO日志,有清理的线程,但PG的原理是没有重做UNDO日志,通过表本身来实现,就会有死的元祖。而不能及时清理死的元祖就会引起一系列的问题。
所以我暂时只能理解,如果你想用甲骨文的方式来管理PG的数据库,则最好表不要特别大,并且数量也不要太多。
那换一个思路我用MYSQL的方式来管理,总能避过上面的担心,但PG对其他库的数据的访问,并不如MYSQL简单,select *从库名。表名
,就能跨库查询,而是要走dblink的方式来连接在同一个实例(PG官方的叫法应该叫集群)不同的数据库。这又是MYSQL数据库管理员所不能理解的,并且也觉得比较麻烦的。
此时就陷入了,PG不好用的一个思维模式中去了,对比ORALCE,对比MYSQL, SQL SERVER都有不同。在既定的模式下,都不能理解这个PG怎么这么怪。站着不行,坐着也不行。
其实我倒是不这么想,学习一个新事物,一定不要抱着原有的思维模式去学,那样可能每件事都觉得,还不如我的那个方便,但实际上,如果你深入到PG的学习中,会发现除了这样的事情以外,PG的扩展性,多态性,也是其他数据库无法进行比拟的。
那我们对上面的问题既然有了一定的认知,我们就能避开某些可能会出现问题的地方,例如,我可以使用甲骨文的方式来管理PG,建立多个模式,但如果一组表与另一组都是无关联的,,那我就在PG的集群上新建一个数据库,将这些无关逻辑的表,放到另外一个数据库中,或者有关联我可以创建跨库视图,来解决需要dblink的方式的烦恼,以适合PG的方式来管他,忘记用甲骨文还是MYSQL的方式来管理PG,因为PG就是PG一个不一样的烟火。
