🙅 🔔 ♂️ 使用HTMS API来处理关系网络数据库 🐮 🗨️ 🥞

引言

在“关系网络数据模型”一文中，提出了HTMS数据建模的新概念，这是规范关系模型的发展。本文将演示如何使用逻辑级API实际使用它的示例。

这些示例与用于创建站点的著名的教育和方法论解决方案相关联-用于在MS Visual Studio中基于Django框架的基于Web的调查项目的模板。

理解本文需要对Python语言和Django框架有基本的了解。

数据库说明

概念数据模式是四个表，并对它们之间的依赖关系进行了描述：

注意事项：

调查中响应的序列号-仅在显示包含调查的页面时用于形成查询集
在站点上注册的调查参与者的名称-仅为注册用户填写（非注册用户可以投票和评论）。注册用户可能会建议创建新的民意调查，但是本文中我们不会考虑这些细微之处。

依存关系：

每个民意调查（ 民意调查表中的行）对应于2个或更多答案答案表中的行
每个答案（“ 答案”表中的一行）对应于0个或多个注释，即评论表中的行
如果站点访问者是第一次投票，那么将在“ 访问者”表中为他创建一个新行。用户通过ip地址标识
每次投票后，对调查中选定答案的投票数增加1
该网站应该记住每个访问者给出的答案以及他留下的评论：每个用户评论都写在“ 评论”表的新行中

使用ORM Django形式化数据库

首先，我们展示如何使用Django包模型的类传统地描述数据库。

注意事项：

民意调查属性可能看起来是多余的，因为可以通过答案列表来获得民意调查列表，但是这样做是为了避免丢失从民意调查中删除答案的事实。
Django会在首次启动站点程序之前根据模型的自定义子类在数据库上物理创建（或修改）数据库。使用在应用程序上下文中执行的python manage.py migrate和makemigrations命令进行建模

使用HTMS对数据库进行形式化

要创建数据库描述，必须定义其类：

Polls_db是调查站点应用程序的主要数据库类。主数据库类定义为HTdb的子类，它在HTMS中充当应用程序数据库的超类（可以有多个）。

民意调查，答案，评论，访问者 -数据库表的类。表格 -HTMS的主要类别之一，是特定表格类别的超类。

HTMS在站点程序执行期间直接创建（或打开现有）数据库。相关选项：

创建一个名为“ polls” 的新数据库 ：
my_db = Polls_db （db_name =“ polls”，新= True ）
- 主数据库文件（“空”）将被物理创建，
- 在OP中，将创建主数据库对象my_db - Polls_db类的实例。
打开一个名为“ polls” 的数据库 ：
my_db = Polls_db （db_name =“ polls”）
- 现有数据库的主文件将被物理打开，
- 对象my_db将在OP中创建，其属性包含有关从其文件读取的数据库的基本信息。

在初始化HTdb子类的实例期间创建新数据库时，有必要在逻辑级别确定实际结构（方案）。该操作在站点首次启动时完成一次，但是与ORM技术不同，此操作在站点本身的程序代码中进行。

定义所有数据库属性-它们的名称和数据类型：
使用链接定义属性类型（默认情况下，其余类型为“原因”类型）：
定义表对象并从GT的所有属性集中为其选择属性（列）：

如果数据库是新数据库，则执行此代码将导致数据库结构的形成以及服务器上相应文件的创建。

如果已经创建了数据库，则只需要创建表类的实例即可使用它：

HTMS与ORM的比较

显然，HTMS和ORM在逻辑级别上对数据方案的形式化是相似的，但是存在许多基本差异。

在HTMS中，属性和数据类型被定义为单个空间；在ORM中，它们被绑定到单独的表。

ORM中的整个数据库属性集是“附加地”创建的，因为定义了模型，因此无法以编程方式更改它们，而是在HTMS中针对整个数据库进行更改，您可以在不迁移的情况下在应用程序中添加或删除它们。

ORM中每个模型的属性都是静态的，而HTMS中的属性是动态的。 HTMS中的表结构被定义为单个属性空间的投影-它比ORM中的表更简单明了HTMS网站算法可以提供更改原始数据库结构的选项，例如，添加新属性或删除现有属性，这在ORM技术中原则上是不可能的。

请注意，如果将HTMS技术应用于Django框架，则仅会扩展其功能，而无需放弃使用ORM。例如，可以使用Django基于模型和User类（来自django.contrib.auth.models模块）的整个出色的身份验证系统。因此，实际上，带有HTMS的基于Django的站点通常将是“多模型”，即，整个数据库的一部分将是纯关系的，另一部分将是关系网络的。