【IT168 专稿】有时候，会有尝试着建立一种数据库技术分类法的需求。这里有分析数据库的八种方法可以参考。这个出发点，是来自每个规模足够大的大企业都需要认识的至少七种来自数据库的挑战。一般应注意的事项包括：

　　·使用“数据库挑战”这个词汇可以避开谈什么是或不完全是DBMS的问题。

　　·“挑战”可以在一个企业中引出多种产品和技术，更别说在这么多企业中所产生的效应了。例如，分析数据库的八种方法可以缩减到一种。

　　·即便是这样，某个产品或技术也可能很适合处理几种不同类型的挑战。

　　几乎所有企业都要面对的七大数据库的挑战是：

　　持久的OLTP(联机事务处理)数据库管理。任何规模的企业都会提出这种需求。最常见的是需要满足基于行的关系型DBMS——Oracle、IBM DB2、Microsoft SQL Server、Sysbase ASE、MySQL、PostgreSQL、Progress OpenEdge等等。

　　·从salesforce.com或Workday, Inc可以看出许多SaaS厂商偏离标准的关系模式；

　　·时常会有面向对象的DBMS工作(或者图形DBMS和其他方面)。

　　·特别在互联网应用中，有时在NoSQL中也会有。

　　网站和网络支持。回首专业网站，情况会有所转变。下面列出了几个方面。

　　·OLTP。虽然OLTP默认是在RDBMS，但许多NoSQL系统也能够满足ACID的简单处理。

　　·内容管理，这可能是最好的文件-指向/动态模式的DBMS所支持的(顺便说一下，动态模式需求可以在反映到OLPT中)。

　　·跟踪用户交互，最常见的NoSQL系统——MongoDB、Couchbase、Cloudant、Cassandra、HBase等等——都非常适合。

　　更重要的是，它可能并不适于在单一的关系型数据库中将真实的OLTP与用户交互跟踪相结合。这方面有一个可怕的例子：Chase在2010年9月的停运。

　　类似的思考可以适用于其他从机器中生成数据的系统，例如社交游戏或传感器网络。

　　内存缓存或DBMS。越来越难想象，OLTP系统或web属性直接到持久存储而不通过中间的内存层。或者说，如果要利用它，是因为当整个工作在RAM中进行时，所用到的持久数据主要用于是如何起作用的方面。除了调查普通的以存储器为中心的数据管理之外，还需要了解关于缓存网格的更多内容。

　　分析支持。无论是对事件监控、趋势监控还是完全的调查分析，都会进行大量的分析工作，同样可以利用大量的数据存储来。有一点不强调这些结构——有时，你会遇到一个真正的专业分析需要你寻找相应的诸如图表存储或SciDB的DBMS。

　　文档管理。人们以文档的格式记录商业信息已有5000年的历史了，从未停止过。企业至少需要配置搜索引擎，或者通过具有其他优势的系统来管理文档。

　　嵌入式数据管理。企业需要管理许多包含内部数据库管理的系统——例如电子邮件、计算机辅助工程、安全应用或日志等等。通常，你可能会忘记包括系统供应商在内的基础数据管理。另一方面，你或许会这样思考——需要把接入这些数据作为计算环境的一部分么?如果是那样的话，或许你需要得到更多的管理或提取的权限。

　　当然，你可能会在自己的业务中发展嵌入式DBMS。可以采取多种形式。通常，当涉及这些情况的时候，所关注的是DBMS，例如内存或中间层而不是困惑于某一产品是通过OEM方式还是直销渠道进行销售。

　　数据整合。会发生在自己的数据库中，同样也会发生在外部的数据库中。通过与许多经典的ETL(提取/转换/加载)接触，会再次与包括Informatica的供应商讨论——而不是Talend，可以不用与其他人进行技术讨论，也不用保密Ab Initio。会有回到SnapLogic，当然还有忽略客户的Syncsort的冲动。

　　在数据集成中的观点是，分析数据存储的数据流的更新越来越重要，这是由低延迟的愿望普遍存在所导致的。有些事情能够并且应当与复制技术共同作用于高可用性、灾难恢复等情况。更先进的ETL功能往往并不需要，现在的ETL已足够使用了。总的来说，企业能够在他们的数据库管理中碰到数据多样性。