Indices or Indexes

Similar to views, our system is equipped to autonomously build indices. This process involves classifying a Definition and a ReferenceType, and introducing a new attribute - the Flag RCFT.

Maintaining consistency in like-terms across classifiers is essential for clarity. Building on our previous definition that included DEFINITION, OBJECT_CREATE, VIEW, COMMON, we extend it to include DEFINITION, OBJECT_CREATE, INDEX, COMMON for our new definition.

Indices introduce an additional dimension, necessitating two more ReferenceTypes: DEFINITION, OBJECT_CREATE, INDEX, DATAPOINT_TYPE_USING and _INCLUDE. Additionally, a new FlagType, DEFINITION, OBJECT_CREATE, INDEX, IS_UNIQUE, is introduced.

What's notable about our system is its user-friendly nature. Team members, even those new to the project, can easily understand the RCFT classifications, providing transparency in the code. For instance, a code snippet might read: "Get DataPointNames where the TypeId is in the DefinitionReference for this definition, and the reference type id is DATAPOINT_TYPE_USING."

At present, each table in our system is equipped with three indices: one delineating what constitutes a UNIQUE record, one for data retrieval based on Tenant and ClassifierId (where definitiontypeid = ), and one for data retrieval based on Tenant and KeyName (in alignment with our get_typeid functions).

Looking ahead, the Index Creator module will evolve to incorporate more logic, such as ALLOW and EXCLUDE DataSet lists or DataSetType lists. The future roadmap includes refining the system to maximize efficiency, moving away from repetitive tasks and letting our system create and remove its own indices. Right now, the goal is to transition our system into a minimum viable product mode, allowing us to unleash its full potential. It's time to put this Lamborghini into drive.