
🧾About the code (Python)
© Alexander Sychev, Sergei Sychev, “TRIZ-RI Group”
Now consider the possibilities which the programmer gains using this data structure.
Clear example
Supposing we need to make a selection (get). Now we can write universal operations in this style:
searches = []
names = ["list all required parameters here"]
for name in names:
searches.append(get(set_id, name, value)) # "Gene" of the data structureFor example, the following code will find all people, all agents, all documents and all goods:
searches = []
names = ["people", "agents", "documents", "goods"] # Look here
for name in names:
searches.append(get(None, name, None)) # Using None as a placeholderWhere None acts as a pointer to a void because the variables set_id and value are not required in the request.
Note: In order to simplify and unify the code, we will try to use this rule regularly: structure
setID, name, valuewill always be used in the corresponding function, but when a particular variable is not needed, we will pass the "pointer to void" instead).
So, if any new entity appears (for example, "Deals"), and we need to expand the query to receive "all the deals" as well, we do not need to write any additional features, we only write corresponding entries in the table Values and Sets of our database (if such entities did not exist before) and specify the "deals" in the "get" function:
You may agree that if data structure was different, we would need to do something like:
And that is pretty bad.
But let's move on. Let's go back to our contradiction: the attributes should be different and should not be different. But let us no longer consider it at the level of the data structure, but at the level of the program code as well.
First let's select "people as people", and display the universal attributes for each of them, such as name, gender, phone, email, weight, height, eye color, etc.
Of course, we do not write function for each attribute:
Let's make our request in the same way we did before:
Now let's choose a different context and select "people as agents". Let us be interested in other attributes. No eye color, height or weight, but, for example, details of the transaction made with us and related products and documents in addition to the contact itself.
We do not write new functions, but only change the parameters in the marked line:
It is clear that if we constantly require a different "set" of settings (people in different contexts: "people", "our employees", "agents", "as employees of the suppliers", "as employees of the Customers company", "as lovers" etc.), we will always use just one function:
We got a function close to the ideal, which does not indicate any entity explicitly (hence, after any reorganisation of data, the code does not change at all), but, nevertheless, it responds properly depending on the parameters passed.
Now let's standardise a requirement to the parameters of the "ideal function". Let it always require only 3 parameters: "Id of set of attributes", "name of attribute", "value of attribute", which represent the "copy" ("gene") of our universal data structure described above (Set_id, Name, Value):
where:
Set_id - Id of set of attributes
Name - name of attribute
Value - value of attribute
Another methodological remark: apparently, code and data are not stored together. As you see, abstraction conducted fairly seriously (see for yourself), and normalization is so strong that even reached its dialectical negation, but there is no encapsulation in OOP sense at all.
We do not mix the data and code that works with it, hence we don't create any objects, neither in general sense nor in OOP sense. The code is universal so it works with any type of data, and any type of data also does not have its "personal code". We do not make "smart objects" we make "dumb data sets" and "dumb functions" separately from each other. The difference with the OOP is obvious.
Continue the optimization
Let us continue the optimization
Any good manual on database design mentions the CRUD, and that all work with databases is reduced to four operations: "Create", "Read", "Update", "Delete".
Let's implement this set of tasks here, considering the idealization of code described above. We shall implement the "dialog" between the program and database via the universal interface ("the kernel"). This interface should be done in such way that the program should not know anything about the databases structure (in a way it should be done by all canons) and the database as well should not care what program is using it. Here we will only list key "kernel functions" (it is an article after all), and if we receive numerous requests to publish the entire kernel, we will publish it separately.
Key kernel functions are: "Get", "Add", "Delete".
Read:
Create & Update:
Delete:
Let us examine them in detail, as they are carrying out the mission of relieving the programmer from a necessity to know the structure of a database and even necessity to know the SQL language. Firstly, because, considering what was said above, the entire SQL language is reduced to very primitive lines, and secondly, "kernel functions" are creating these lines, and the kernel itself sends retrieved data where it is required.
Function "Get"
As stated above, the Get function is also responsible for the automatic creation of SQL queries
Supposing we want to get a attribute of set with the identifier Set_id = 1.
We should fill in the functions parameters Get ( Set_id, Name, Value) as follows:
and following SQL-queries will be created and executed:
If we change the input as follows:
will create and execute following SQL-queries:
Or as follows:
will create and execute following SQL-queries:
Or as follows:
will create and execute following SQL-queries:
Or as follows:
will create and execute following SQL-queries:
Or as follows:
will create and execute following SQL-queries:
Function "Add"
Now let's take a closer look at the "Add" function:
For example,
will create and execute following SQL-queries:
For example,
will create and execute following SQL-queries:
Such variation is also possible:
Here the function ADD "cleans up" the database, ie removes the value that no one uses anymore.
You can pass multiple names and values at the input of the ADD function:
Then it creates an entire set with specified attributes:
Function "Delete"
Let's take a closer look at the "Delete" function:
will create and execute following SQL-queries:
will create and execute following SQL-queries:
And we'll talk about performance in the next chapter.
Last updated