关系模型已经失去了排他性
在关系系统中最充分实现的数据库功能和结构（DB）的要求现在正面临新要求的压力。
第一个问题是大数据的效率低下。 大数据的来源是社交网络，视频监视系统，空间传感器，计费等。 如果在启动应用程序之前预先精确定义了数据模式，则关系数据库（RDB）可以很好地工作。 但是在数据库设计阶段，大数据本来就很难构建。 只有逐步收集信息，其结构才会更加明显。
第二个 -在具有庞大表的RDB中搜索，计算查询-这是算法复杂度很高的任务。 索引和哈希的使用在或多或少的静态BDB中效果很好，这些BDB在系统投入运行之前已被大量填充。 并且在实时快速到达新数据阵列的条件下，这些方法的优点得以平衡，因为间接费用急剧增加。
RDB 的第三个缺点是在规范的“规范形式”框架内对数据电路的严格要求。 对大量各种各样的应用程序的需求需要大量的努力来创建数据模型，程序员技能水平的不均衡和紧迫的期限会导致需要更正和更改的错误。 但是，任何已经“存在”且充满DBD（“迁移”）的更改都是一项更加复杂且费力的任务，在某些情况下根本没有其他解决方案，例如用新数据库完全替换旧数据库。
用SQL实现关系模型的“美”和严格性，已经持续了30年，这使程序员感到高兴。 “旧”模型：网络或分层模型几乎被遗忘了。 是的，除了“几乎不朽”的IDMS [1]以外，几乎没有这样的软件产品。
在过去的十年中，正在积极创建替代数据库管理系统（DBMS），即NoSQL。 在这个概念下，现在存在非常不同的系统，它们彼此之间非常不同。 有趣的是，“旧的”网络和分层模型没有包含在NoSQL的概念中！ 在[2,3,4]中可以找到这方面的好评。
NoSQL类别包括“图形”数据库[5]，抽象地接近规范网络模型CODASYL [6]。 顾名思义，此类系统是两个无组织的集合-节点（顶点）和边缘（弧）。 网络数据库的主要优点-导航不是像在RDB中那样在处理请求时“确定”的，而是在添加新数据 （对于图形-顶点和边）时“确定的”，对于图形系统而言，这是完全正确的。 但是，与CODASYL数据库不同，图形数据库在填充之前并未进行结构化。
其他最受欢迎的NoSQL数据库类是“键值”（例如-Redis [7]）和“文档存储”（例如-MongoDB [8]）。 由于对此类系统的详细审查不是本文的目的，因此仅注意以下几点很重要。
通常，NoSQL系统在提供可伸缩性和可靠性的分布式文件系统的基础上运行[9]。 但是在关系模型的框架内数学上严格解决的问题是数据库的完整性和一致性 （当然，要提供标准化方案的专业能力设计）在大多数NoSQL系统中根本没有提出。
总体而言，今天的情况大致如下：75％的数据库是关系数据库，其纯格式的NoSQL用于高度专业化的系统中，各种数据库模型的组合用于高度负载的全球网络项目中：Google，Facebook，Instagram，WhatsApp等。
没有SQL的关系数据库
除了上述实际问题之外，RDB的使用最近还看到了其他重要趋势。
除了有时候关系模型的“刚性”过高之外，它的主要实际 （而非理论）缺点是数据处理的复杂性。 第一种选择是对集合使用操作流水线-统一，交集，过滤等。 实际上，它几乎从未使用过，因为它与巨大资源的消耗相关联，并且仅通过对同一类型的请求集进行“批”处理才是合理的。 第二种选择-SQL解释器需要很高的专业素养，对集合论，数据库理论的深入了解和相当的实践经验。
面向对象编程（OOP）已成为标准，但是SQL是一种声明性语言，其语法与最常见的OOP语言（C ++，Java，JavaScript，Python）不匹配。 结果，基于称为ORM（对象关系映射-对象关系映射（转换）[9]）的类库的“嵌入” RDB（与SQL查询一起使用）的解决方案已经普及。
使用ORM类使程序员在使用RDB时无需使用SQL。 ORM自动向RDB生成SQL查询，以创建表和处理数据。 大多数ORM都具有与各种流行的DBMS的接口-SQLite，MySQL，PostgreSQL和其他，这些接口可以选择而不修改程序代码。
有很多ORM实现，甚至每种编程语言都有几种。 它们都是相似的，因此，为了明确起见，在将来，ORM指的是Python语言[11]中Django框架[10]的Model类的模型的相应库（包）。
ORM非常“方便”，程序员并不真正认为使用此API不仅会获得关系模型的优点，而且会获得其所有缺点。 例如，在代码本身中，您无法覆盖表模型-添加或删除列，添加新表等。 要进行数据库迁移，必须首先重写代码，然后“再升高一层”，然后重新启动程序。 结果，不可能创建在程序运行过程中即使对数据方案进行最简单更改也不会更改程序本身的应用程序。
ORM中的数据检索是使用方法链来实现的，例如Django中的“ objects.all（）”，“ objects.get（...）”，“ objects.filter（...）”。 简单，美观和方便，但是执行由ORM生成的SQL查询的算法复杂性将导致什么用肉眼看不到。
当一个人写一个SQL查询时，假定他在思考并理解计算资源的成本。 ORM掩盖了此任务。
Hypertable作为新一代数据库
我们已经开发出一种新的概念，方法和实践方法，将关系数据库和网络数据库模型与ORM想法的优点结合在一起-拒绝使用特殊的查询语言，这使我们能够创建新的数据库模型和技术。
关键概念是超表 （GT）-这是一个数据库，其中包含一组关系（表），其中使用：
- “关系”属性（数据域），其值（如RDB中一样）是具有对应表列的自定义数据的字段字段
- “网络”属性（链接域）。 我们称它们为ATS-类型为“链接”的属性
表行中的PBX字段的值是对超级表中包含的任何表中任何行的显式引用。
我们引入的超表概念与项目[13]无关，该项目于2016年被缩减。
HTMS（超表管理系统）是一个有效的原型-一组Python工具-HTMS（超表管理系统），包括以下级别（从上到下）：
- HTed超表编辑器（客户端）是在Django框架上实现为网站的技术支持服务，无论应用程序如何，它都可以连接到具有超表的任何服务器（在某种程度上，它与PostgeSQL的PgAdmin实用程序很接近）；
- 实用程序和逻辑级别类的库-用于在应用程序编程级别创建数据库和操作数据的API（替换ORM）；
- 与数据库一起使用的物理级别的实用程序和类库，逻辑级别的实用程序和类基于该库（有经验的系统程序员如何使用API）；
- Cage类，用于在客户端（应用程序）侧创建对数据库文件的缓存远程访问的“虚拟”层；
- CageServer文件服务器-在多程序和多线程模式下工作的软件，实现了使用TCP协议实现多用户远程访问服务器上文件的功能。
原则上，可以使用操作系统的常规本地文件子系统代替Cage来管理文件，还可以使用Cage API和CageServer软件作为HTMS的独立工具来在任何系统上实现远程分布式文件访问。
在以后的文章中，计划将读者更详细地介绍HTMS系统。