【51CTO精选译文】我是位NoSQL用户，同时在大数据方面也广有涉猎。这种技能组合相当应景，正如大家所看到，如今数据库技术人员讨论最多的可能就是“数据增长失控”这个话题。
正所谓“积习难改”，关系数据库管理系统仍然稳居业界主导之地位。然而即使大家是彻头彻尾的甲骨文粉儿、为老式RAC中的PL/SQL架构所深深吸引，也请稳下心神、保持冷静。时代不同了，如今我们需要在着手执行任务之前认真考量，而绝不能仅凭个人好恶来选择解决方案。
1. 搜索: 即使是最敬业的甲骨文专家也会尽量避免使用Oracle Text组件。尽管甲骨文公司斥资将其纳入自家数据库产品，但其实际表现相当乏善可陈。相反，我们会看到很多用户还在使用like及or等命令实现复杂的查询工作。由此引发的结果自然是使用者抱怨满载、实际性能羸弱不堪——而且甲骨文公司所设定的数据获取方式本身也令人极为恼火。当然，甲骨文并不是惟一一家在搜索功能方面有所欠缺的厂商。除他们之外，大多数其它RDBMS产品也没能实现真正的搜索扩展。
在Hibernate Search、Apache Solr或者Autonomy的帮助下，我们能够获得更好的检索性能表现。别犹豫，让它们成为大家全文本搜索工作中的有力助手吧。
2. 推荐: 我用过大量ATG及其它商用类产品，这项功能绝对是我见到最令人无法忍受的东西。产品会追踪使用者的大量日常信息，并尝试推荐用户可能需要的其它产品。凡是我工作过的地方，一般都会出于可扩展性方面的考虑而把一切推荐功能第一时间关闭掉。
大家不妨设想社交网络的运行情况。如果我希望某位用户能够购买他（她）的朋友以及朋友的朋友所选购的袜子，这种跨越式关系会让RDBMS非常被动。要实现这一诉求，我们需要采用自连接表格与多查询层。这很像是Neo4j等图形类数据库中的两行代码。虽然大家可以通过对社交网络架构的预扁平化及数据临时调整达成目标，但这也会令关系数据库失去其实时性。
3. 频繁交易: 大家可能会以为交易系统是RDBMS的长项所在，因为数据多少都会蕴含一些交易属性，不是吗？错。我甚至怀疑第一个将频繁交易通过NoSQL实现的操作者就是NoSQL开发团队中的一员。频繁交易活动中，低延迟是最关键也最宝贵的因素。没错，如果大家跳出固有思路，也能在RDBMS中获得较低的延迟效果——但我还是提醒各位，关系数据库在设计上并不适合这类任务。
甲骨文公司试图通过收购TimesTen来解决这一难题，后者一直在努力将内存数据库与RDBMS相结合——然而上车就算加了翅膀也不会变成飞机，我们只能把这看作一定程度上的小小改善。相反，我们倒是发现很多频繁交易操作者自发选择Riak等键-值方案甚至是更为复杂的Gemfire。
4. 产品目录: 这一条看上去似乎平淡无奇，但我曾在之前的文章中谈到，我个人工作中最可怕的SQL查询噩梦之一正是产品数据映射工作。当时我正为一家移动电话制造商工作。手机这东西大家都知道，同一个型号“XYZ”有可能代表着多款机型，而且这些机型在不同的市场中还被赋予了不同的“昵称”。甚至同一款机型也会使用多种差异化组件。要想对这类复杂而模糊的“类”进行扁平化处理简直难于登天，因此在处理此类工作时，以Neo4j为代表的图形类数据库就成了上上之选。
后来我供职于一家化工企业时也遇到过类似的问题。当时我们选择的字符映射方案非常愚蠢、极耗人力。而在把产品信息转移到图形类数据库中后，映射工作就变得简单易行了。甚至像CouchBase 2.0或者MongoDB这样的文件数据库都比关系数据库表现得更好。
5. 用户/群组与ACL: 在某种角度来看，LDAP其实就是最原始的NoSQL数据库。LDAP专门为用户、群组及ACL所设计，能够恰到好处地满足此类需求。遗憾的是，很多人都出于误解而将其作为新技术的衍生品，企业也试图用它来处理某些荒谬甚至可怕的任务。还有不少公司用它建立起一套官僚意味浓厚的管理机制，许多开发人员为了免受影响只能被迫通过篡改数据库表格来维护日常工作流程。这显然有违集中式用户访问控制的初衷。我认为，“用户”与“角色”等表格在任何企业环境下都毫无必要，应当早日摒弃。
6. 日志分析: 如果大家还不清楚这方面问题的危害，不妨打开Hadoop或者小型集群服务器版本RHQ/JBossON中的日志分析功能，设定日志级别、让日志捕捉除错误之外的其它信息。执行过程越复杂、我们的工作状态也就越混乱。可以看到，像日志信息这样多少带有些非结构化特性的数据，正是MapReduce公司的Hadoop以及像PIG这样的语言所擅长的领域。然而我们遗憾地看到目前各类主流监控工具仍然在以RDBMS为主要对象——关系数据库根本不需要这么多分析及汇总工作，低延迟才是其最大卖点及首要诉求。
7. 媒体资源库: 虽然保存元数据的效果还算可以（其实Couchbase 2.0或者MongoDB在这方面表现更好），不过RDBMS中的BLOB在经过了多年的演变后仍然很不给力。大家最好为自己的图像及其它二进制文件选择某种类型的分布式存储方案或集群文件系统。尽管表现令人失望，许多CMS引擎仍然会把一切存储任务都推给RDBMS，这也是大家需要注意的一点。
8. 电子邮件:我知道，这一点几乎已经成为共识。在项目完成、着手将电子邮件整理到RDBMS当中时，我发现很多人已经明白：电子邮件实际是一种具备适度非结构化特性的元数据，而关系数据库并不擅长存储这类资料。我们已经尽可能对RDBMS进行了优化，最大程度修整BLOB等相关组件。然而电子邮件管理工作涉及到元数据、搜索以及内容，这些东西之间并没有明显的关联代数可供参考，而且与交易扯不上关系。关系数据库本身的文件系统没有问题，只是文件类数据库在处理元数据时表现更出色。
9. 分类广告: 广告是一种规模庞大的信息集合，海量用户查询及发布这类数据，其内容短小却极具吸引力。Craigslist这家知名广告网站使用的正是文件类数据库MongoDB，它擅长搜索、打理元数据、非常适合广告的固有特性，连信息一致性也有足够的保障。面对几乎等于是为广告量身打造的文件类数据库，RDBMS最好的选择就是绕道而行。
10. 时间排序/预报: 这一点在本文的十大排行中最具普遍性，但其具体表现形式却多种多样，从商品到数据分析再到太阳黑子预测都包含在内。关系数据库在时间排序问题方面的表现一直饱受争议。当然，现在情况已经大大改善；而且经过过去十几年的努力，RDBMS在与时间有关的处理效率及功能方面已经摆脱了严重缺陷的尴尬境地、取得了令人瞩目的进步。然而如果大家把时间类任务作为主要处理对象，那么像Cassandra这样能够与MapReduce列簇产品家族良好对接的方案无疑更为理想。Datastax公司已经明显指出，其Cassandra发行版将支持时间排序数据；其它一些供应商也纷纷在产品中推出类似功能。
除了前面所提到的内容，大家还在哪些领域使用RDBMS？我和大家一样，每天都离不开RDBMS；但它真的是最好的解决方案吗？不一定。也许某些老顽固会努力为RDBMS开脱，但我们得承认，单单是使用习惯远不足以支持关系数据库一路走下去——在恰当的情况下使用恰当的工具方为明智之举。
原文：10 things never to do with a relational database
