When we consider table designs, it's common to think of them as mere storage units for data. However, in our sophisticated system, tables are not just for storing data—they are for managing it. Each table is equipped with the same 15 columns, serving various functions that go beyond simple storage. Very few tables have additional columns beyond these and their descriptors.
Among these columns, we find flags that enable records to reroute themselves to correct data automatically. For instance, a misspelled 'Oregone' can be seamlessly redirected to 'Oregon', ensuring data integrity without manual intervention. Additional flags indicate whether a record is active or trusted, allowing the system to handle untrusted data differently.
A keyname column is also present, which allows developers to reference records in code, enhancing readability and flexibility. This approach moves away from rigid queries like 'where id = 5', making the code more intuitive and maintainable.
1
2
3SELECT fnc_relationship_get_typeid(
4 @tenantid
5 , 'PERSON'
6 , 'PERSON'
7 , 'DIRECT'
8 , 'FAMILY MEMBER'
9)
10
11
Two sorting columns, one numeric and one alphanumeric, facilitate the organization of data, while the primary key and hierarchical ID establish relationships within the data. Multi-tenancy is supported for every record through a tenant column, and a table Id column represents the table in which a record resides. A globally unique identifier (GUID) ensures that each record is uniquely identifiable within the system. What appears to be duplicated data, can be data owned by a different tenant (customer or a template). This allows us to clone aspects of the system functionality and modify it specifically for the client.
Parameterization is a core feature of our system, allowing any stored attribute to drive content, security, or planned actions. This flexibility enables the system to handle data differently based on existing Cartesian relationships. For example, content can be tailored in multiple languages, displayed at different times of the day, and even influenced by a user's cholesterol level or frequency of page visits. A record(s) can be pre-deployed, be accessible or disabled within a time-frame (or run a job). And every record in the system can have tailored security measures. While the record has to exist in the system, the object does not. This allows me to control security on my APIs from the database.
By approaching data storage as data management, we empower ourselves to govern our system effectively. This consistent structure allows us to automate the creation of tables, views, databases, indexes, defaults, and even retrieval functions. Our system's design ensures that we can store and manage any type of data, and we do it consistently. This eliminates truncation issues caused by different developers defining the same type of data in different tables, and other human err in the design of core objects.
The system's adaptability also extends to machine learning and AI processing. Data-driven pivots, supported by our table design, enable the production of numerous feature combinations. These combinations are crucial for informing algorithms and achieving high-quality data analysis.
In summary, our system's table design philosophy transcends traditional data storage concepts. By embracing a holistic approach to data management, we ensure that our databases are not only repositories of information but also dynamic tools that adapt to our needs and enhance our capabilities. This innovative mindset is what sets our system apart, making it a powerful ally in the ever-evolving landscape of data technology.