对关系型数据库局限性的重新思考

在NoSQL的历史上有很多曲折反复，所有曲折进程和定义不明确算所带来的最不幸的一部分，就是失去了一些很有价值的东西。这篇帖子不是关于Nosql定义的不同，而是表明所有被归类为专属于无模式的的 数据库世界中的巨大好处，也可以轻松应用到关系数据库世界中。

　　忘掉迁移

　　也许关于提到无模式数据库最大好处就是你只要一提交代码就它可以很好的 工作。大约五年前Heroku发布 git push heroku master部署平台让你可以轻松的在git上面提交代码并让他工作，CouchDB 和 MongoDB在数据库方面做了样的事情。在你在数据库上工作时你没有必要运行 CREATE TABLE 或 ALTER TABLE进行迁移。你只要构建和发布你的程序而不用担心数据迁移是多么棒的事情啊。

# Assuming a column thats referenced doesn’t exist
# Automatically execute relevant bits in your ORM
# This isn’t code meant for you to run
ALTER TABLE foo ADD COLUMN bar varchar(255); # This is near instant
# Set your default value in your ORM
UPDATE TABLE foo SET bar = ’DEFAULT VALUE’ WHERE bar IS NULL;
ALTER TABLE foo ALTER COLUMN bar NOT NULL;

 

　　这经常被看做是关系数据库的一个局限，然而其实没有必要。你可以看到即使在无模式的数据库中关系依然存在，只是你在应用层操作管理它。说在更高的框架层次或使用ORMs无法处理数据迁移过程是没有道理的。在今天，在没有引入当机时间和可以让开发者更快的迁移没有自动拷贝的数据的意义上，给关系数据库添加一个字段的过程还是很简单的。

　　Rails/Django(你选用的框架)已经注意到让数据列存在的需求，适当的修改后你可以在你代码中像管理文档关系一样的方式使用它，当然这是一个共同的让人懊恼的的过程，但是说它不能被PostgreSQL完全处理和在ORM中不能直接处理它是没有道理的。

　　 文档

　　其他一个强有力的说明例子是针对与MongoDB/CouchDB阵营的文档存储，在这个例子中我将给出文档直接转换为JSON对象的替代方案。JSON在移植性方面是一种很棒而又简单的数据模型，但在应用层你必须要转换它却也是一件很痛苦的事情。是的你看到的没错，Postgres现在有个JSON数据类型，而且JSON数据类型也不断的被一些其他的关系型数据库所采用。当我没有奢望她在JSON上的改进时， DB2对JSON的支持有点令我吃惊

　　在数据列中存在JSON 格式是很有意义的，在你想把所有的结果当做整体JSON对象的时候，作为完全的JSON存储还是有点限制。Postgres 的一大买点就是你只用一个存储过程row_to_json就可以把一整行转换为JSON对象。

　　还有就是你有一些高层框架可以利用，在它们的支持下，你可以一边让那些强类型的数据表存在，但一边你可以灵活地将他们映射到JSON对象，这样是很有意义的。

　　 出箱即用的接口

　　这不是无模式数据库的专属特性，无模式的数据库中一些比如Couch 开箱即用特性多一点，另一些少一点。曝露一些rest 风格的接口的概念并不是新创的，不久前已经在关系数据库上实验过了。一些事情显然需要重申一下，这个例子清楚的表明，在重新构建操作界面和降低新手的入职门槛方面，确实降低了时间。

　　不幸地是，现在对于Postgres 或其他关系数据库，并没有十足的进展。相反地其他数据库从一开始就提供这些接口。

　 　何去何从

　　在无模式数据库或其他更广泛的数据库中，这种转变并不是很大，它们没有纳入更多的选择。然而同时这种转变有很多益处，最显著的一个就是，对传达怎么扩展所谓的”关系型数据库”产生了积极的影响。