Prototype Data Model

    In the prototype data model, objects are created based on other objects. In this case, the object has a prototype, it can still be called a standard or inherited object. There are no types or classes in this data model. Objects can be distinguished by who they prototype, but this task is secondary. Prototyping is primarily used to reuse existing structures from objects.


    An object is an elementary entity that has a name, a value, and some other attributes that are standard for all objects. You can name an object in different ways, but as you call it, it will mean. The value is scalar; it can represent numbers, addresses, dates, file paths, text, and more. The length of the value is not limited. Elementary objects provide the flexibility to build complex structures.

    To represent complex data structures, such as catalogs, products with many properties, objects are structured in a hierarchy. Each object is able to have an unlimited number of objects in its subordination, while being subordinate to only one other object, which it does not have in its subordination. The usual hierarchy of objects. With the help of hierarchy, humanity has long been structured knowledge of the real world, it is a natural and convenient way to present information. Hierarchy in everything.

    But one hierarchy does not simulate objects of the real or imaginary world. For example, a product cannot be placed simultaneously in several directories. It is necessary to link objects from different branches of the hierarchy.


    At this stage, a prototype model is emerging. In addition to the name and value, each object without exception can have a link to any other object, wherever it is. It is a link that forms a connection with the prototype. The link is implemented by an additional attribute of the object representing the prototype identifier. An object can have only one link.

    Now you can add an existing product from another catalog to the desired catalog by creating an object of the product, prototyping it from the product of the second catalog. In fact, a new product will appear, but without duplication of properties (subordinate properties of the product). Turning to a new product, we can operate on the properties of its prototype.

    But the goods in the store may have a different set of characteristics: size, color, while having the same article, name, manufacturer and not a small list of other properties. With a prototype data model, you just need to add redefinable properties in a new prototype product, in particular, add a color property with a specific value. Now the new product has its own color, and the remaining properties will be taken from the prototype.

    Prototyping allows you to reuse objects, create new ones based on existing ones, modify and supplement them without affecting the original ones, directly solve problems, and not create metadata to solve them.


    Having data structures is not enough. They need to be revived by endowing objects with logic. Logic is implemented by the methods (functions) of the object. There may be methods for checking the object before saving, methods for processing requests, generating a mapping, and any others. It all depends on the purpose of the object. When prototyping, a new object, along with the properties of the prototype, inherits its logic, of course, with the ability to complement and redefine it.


    Surrogate keys, such as integers, are usually used to identify objects. Due to the lack of boundaries between the binding of one object with any other, the uniqueness of the key must be ensured within the entire data structure. Therefore, it is ideal to have an unlimited range of values ​​for the key. More precisely, the unattainable limit of values ​​within the framework of the designed system. But the problem is not this, but the existence of objects that cannot constantly possess a surrogate key, since they themselves are created at the time of access to them and at the time of their use. They are not in the database, which means there is no way to access them by key.

    There are two ways to implement prototyping. In the first method, the prototype is completely copied, the new object receives copies of all the subordinates of the prototype. In cases of prototype changes, it is necessary to update all prototyped objects and their subordinates that have not yet been redefined. The downside is the complexity of updating and duplicating data, but we can identify any object.

    The second method involves only establishing communication with the prototype. No need to copy and update anything. But when we operate on an object having a prototype, and we turn to the subordinates of the prototype, these subordinates must be perceived as subordinates of the operated object. In cases of modification of such subordinates, the changes in no case should concern the prototype. Modified objects must be saved as new subordinates of the operated object. Until the objects are saved, they are virtual, temporarily created by prototyping from the corresponding subordinates of the prototype. Such objects cannot be accessed directly, it is necessary to access them from their parent, since their existence depends on the parent.

    Whatever the objects, they still need to be identified. You must be able to refer to an object (predefine a connection) even if the object is absent. The use of object naming will help here if you make their names unique within the same nesting level. Then the objects can be accessed via the path to them, as to files.


    The prototype data model is distinguished by its flexibility and naturalness of the structure. You don’t need to make excuses for auxiliary entities, for example, to implement many-to-many relationships, design data structures, trying to provide all the options for the development of the project, because in cases of which you only need to transfer the data to another branch, anyway, what to do a permutation in room without redoing its layout. But, due to the lack of ready-made solutions, the prototype model has to be modeled on other data models. For example, on relational, from which various problems and limitations are manifested. I will leave this question open for discussion. If anyone undertakes to create a DBMS with a prototype model, call me on the team.

    Additional information:
    1. Application of the model in the CMS
    2. Implementation in MySQL taking into account horizontal scaling:

    Also popular now: