昨天，在TSS上又发布了一篇供应商的市场营销声明。我通常忽略这些，但当涉及到数据管理时，我不得不回应。让我惊讶的是，我们Java开发者对数据管理的了解仍然如此之少。以下是讨论线程中Maxim Kramarenko所做的一项声明
"OO/network DBMS can be very useful when you need to handle large hierarchies - simple graph navigation can be times more fast and simple way to fetch data then SQL. Even ORACLE START WITH/CONNECT BY statement works VERY slow for hierarchies."
现在，这个声明将几个根本不同（且重要）的事情混合在一起，最终让人比帮助更多的人感到困惑。我表达了我的怀疑（是的，我应该更加详细和友好...），然后被要求参与讨论。以下是我的（相当长）回应
如果我想获取数据的层次结构视图（我认为这是涉及数据层次结构时最常见操作），我会使用我的数据库管理系统提供的EXPLODE运算符。如果不存在这样的运算符或者我发现其性能特性无法接受，我会联系我的DBMS供应商并投诉，直到他们修复它。当然，我只有在优化查询执行计划等之后才会这样做（这应该消除了大多数问题）。
如果所有这些都还不够，我可能会考虑使用嵌套集模型或物化路径来表示我的树信息，这是简单邻接表的变体。这绝对是我最后会采取的措施（这在今天我们拥有的SQL产品质量较差的情况下仍然发生得太频繁），并且高度可能只适用于读为主的树。我们在SQL中拥有的，递归的WITH foo as ()或专有的CONNECT BY变体，不一定是我心中所想的良好EXPLODE运算符。但请参见下面的参考，以获得更好的完整解释。
如果我在我的数据库管理系统产品中找不到一个好的操作符，我绝对不会放弃从关系数据模型中获得（在SQL中非常罕见）的任何优势。毕竟，它是一个逻辑数据模型，任何性能问题都是物理实现细节。我看不出这两者之间有什么关系，但我知道如果我们开始混淆两者之间的区别，我们就处于糟糕的状态。没有理由说基于网络/图的关系逻辑模型或关系模型不能具有相同的性能特性。仅仅因为某些产品没有实现最优，并不意味着我们应该放弃数据独立性的整个概念！
向您的数据库管理系统供应商投诉。问他们为什么他们的产品没有完全支持最先进的数据库关系数据管理，例如关系（可能为多态）数据类型系统，或者支持闭包/爆炸的数据层次结构的查询语言。今天SQL产品中的不足之处比这要长得多。如果你在特定产品中无法做到某事，或者如果规范存在严重问题，这不是数据模型的错。
如果让人们对逻辑数据模型和物理实现感到困惑，销售人员很容易向你推销他的旧酒。最终，这对所有人都有害，因为我们都必须告诉我们的软件供应商我们希望看到什么，以及我们需要的支持。如果我们不能清楚地表达我们的需求，如果我们忘记了历史（即过去什么有效，什么无效），我们可能会被骗。我不舒服。
最后，我可以推荐的一本书是Fabian Pascal的《数据库管理中的实际问题》。这是一本小书，只有250页。Fabian展示了你将在日常实践中遇到的10个常见问题，但他不是简单地解释如何通过SQL解决问题，而是首先解释每个问题的关系数据模型基础知识。然后他审视当前的实践，并解释你可以在SQL中做什么（或者我们在数据库管理系统中需要什么）来解决或绕过问题。周末快速阅读，绝对推荐。如果你想复习你的数据管理基础知识，可以和Chris Date的《数据库系统导论》一起购买。
