Notes:

• The polls attribute may seem redundant, since it is possible to get the list of polls through the list of answers, but this is done so as not to lose the fact of participation in the poll if the answer is removed from the poll
• Django physically creates (or modifies) the database before the first start of the site program based on user subclasses of models.Model using the python manage.py commands migrate and makemigrations that are executed in the application context.

Formalization of the database using HTMS

To create a database description, you need to define its classes:

Polls_db - the main database class for the survey site application. The main database class is defined as a subclass of HTdb, which in HTMS serves as a superclass for application databases (there may be several).

Polls, Answers, Comments, Visiters - classes for database tables. Table - one of the main classes of HTMS, serves as a superclass for classes of specific tables.

HTMS creates (or opens an existing) database directly when the site program is running. Relevant options:

1. To create a new database with the name "polls": my_db = Polls_db (db_name = "polls", new = True )
   • the main database files ("empty") will be physically created,
   • in RAM the main object for the database will be created my_db - an instance of the Polls_db class.
2. To open the database with the name "polls": my_db = Polls_db (db_name = "polls")
   • the main files of the existing database will be physically opened,
   • an object my_db will be created in RAM, the attributes of which contain the basic information about the database read from its files.

When there is a new database created during the initialization of the instance of the HTdb subclass, it is necessary to define the actual structure (scheme) at the logical level. This is done once at the first launch of the site, but, unlike the ORM technology, in the program code of the site itself.

1. To define all database attributes - their names and data types:
2. To define attribute types with links (the rest will be типа cause ’by default):
3. To define table objects and select attributes (columns) for them from the set of all attributes of the GT:

The execution of this code will lead to the formation of the database structure and the creation of the corresponding files on the server, if the database is new.

If the database has already been created, to work with it you only need to create instances of table classes:

Comparison of HTMS and ORM

Obviously, the formalization of the data scheme at the logical level in HTMS and ORM are similar, but there are a number of fundamental differences.

In HTMS, attributes and data types are defined as a single space; in ORM, they are bound to separate tables.

The whole set of database attributes in ORM is created "additively", as models are defined, therefore they cannot be changed programmatically, but in HTMS - for the entire database as a whole, and you can add or remove them in the application without migration.

The attributes for each individual model in ORM are static, and in HTMS they are dynamic. Tabular structures in HTMS are defined as projections of a single attribute set - it is simpler and clearer than in ORM. The site algorithms on HTMS can provide options for changing the original database structure, for example, adding new attributes or deleting existing ones, which is impossible in principle in ORM technology .

Note that HTMS technology, if applied in the Django framework, only expands its capabilities and does not require the abandonment of the use of ORM. For example, Django’s entire excellent authentication system, based on the models and the User class (from the django.contrib.auth.models module), can be used. Therefore, in reality, a Django site with HTMS will usually be “multi-model”, that is, one part of the overall database will be purely relational, the other tabular-network.