😎Questions and Answers
about Ideal Data Structure
What is Ideal Data Structure?
The ideal data structure, as inspired by TRIZ and the quest for the ideal in programming and data organisation, is characterised by two main principles:
The ideal program is one that can be maintained and even improved by a programmer with a lower qualification than the author, and even without the author being involved.
The ideal program is one that does not require any changes or additions to the code when new functionality is added. In fact, for an ideal program, increasing functionality leads to a reduction in the amount of code, without any harm to any of its characteristics (for example, performance).
What's the ideal data structure consists of?
The ideal data structure, as described, consists of two main tables: 'Sets' and 'Values'. The 'Sets' table links to the 'Values' table through the Value_id field, which acts as a foreign key in the 'Sets' table pointing to the unique identifier in the 'Values' table:
The 'Sets' table, which has three fields:
Set_id (integer)
Name_id (integer)
Value_id (integer foreign key to table Values not None)The 'Values' table, which stores unique values of properties with two columns:
ID (integer)
Values (string)This structure allows for efficient data storage and retrieval, minimising duplicate records and maintaining good performance even as the database grows.
The approach eliminates the need for a separate 'Names' table by using a dictionary or list of constants in the application code to map human-readable names to their corresponding IDs, thus further optimising performance.
How is data redundancy minimised in the ideal database structure?
All the properties/attributes are moved from appropriate 'Properties' table (except Id) into separate 'Names' and 'Values' tables, which store only unique names and values of properties respectively.
This change prevents the creation of duplicate records for identical properties, as properties are 'grouped into sets' in the 'Sets' table, significantly reducing redundancy.
Further optimisation is achieved by eliminating the 'Names' table, leaving only two tables: 'Sets' and 'Values'. This final structure ensures that data redundancy is minimised by storing only unique property names and values and linking them efficiently through sets, thus saving space and improving performance.
What happened with the 'Names' table?
The 'Names' table was effectively eliminated in the process of optimising the database structure. Initially, it contained two columns: 'Id' and 'Names', both storing only unique values. However, it was determined that the second column, which was used only for the understanding of what was being worked with by the programmer (and not by a user or a program), could be discarded.
This led to the decision to use only the column 'Id' since searching through numerical identifiers is faster. Eventually, the entire table 'Names' table was removed, and identifiers previously put in the table 'Sets' in the field 'Name_id' were tracked directly, leaving only two tables in the database: 'Values' and 'Sets'. This change significantly improved performance by eliminating the need to go through the entire 'Names' table to determine the numerical identifier corresponding to a string parameter.
How are property names and values managed without the 'Names' table in the database structure?
In the absence of the 'Names' table, property values are managed by utilizing a list of constants stored in a header file, which acts as a dictionary.
This list contains a set of constants that correspond to the names of properties, allowing for the identification of property names through their associated numerical identifiers rather than string names.
This approach eliminates the need for the 'Names' table, thereby improving performance by avoiding the comparison of a large number of strings.
The constants in the header file provide a readable form for queries, making it convenient for programmers while maintaining efficient database operations.
Last updated