About Sanka Associations: Differences from RDB Relations
About Sanka Associations: Differences from RDB Relations
In Sanka, associations between objects are represented as "associations."
Unlike traditional RDBs, where foreign keys are embedded directly in records, Sanka treats the relationships themselves as independent objects.
This section will clarify what associations are, how this differs from conventional PK/FK-based design, and the role of association labels.
With associations, simply adding a record enables the creation of a new relationship. In contrast, in RDB, adding a foreign key necessitates schema modifications and migrations, making it difficult to quickly provide custom relationships for each client. Q. What is an association label?
A label defines what a particular relationship means and between which objects it is permitted. It centrally manages elements such as the display name in the UI, selectable targets, and one-to-many constraints. Q. How is data integrity maintained?
Instead of rigid constraints such as foreign keys in an RDB, integrity is maintained through application-layer logic. It is also possible to reset specific labels or enforce uniqueness constraints.
Unlike traditional RDBs, where foreign keys are embedded directly in records, Sanka treats the relationships themselves as independent objects.
This section will clarify what associations are, how this differs from conventional PK/FK-based design, and the role of association labels.
Sanka Association Model
In Sanka, associations are managed using the following two-layer structure.Association (Relationship Blueprint)
- Fields:
Label,Source Object,Target Object,Type,Creator,Creation Dateetc. - Role: Metadata that expresses “which objects are linked, under what name and constraints.”
Source Object/Target Objectcontain objects such asOrderorContact, and are used for candidate control in the UI.
Type toggles between One-to-One / Many-to-Many, restricting selection in the UI and service layer.
- Mechanism: Connects arbitrary object records via a unique ID. Design options such as One-to-One, One-to-Many are available.
Conventional RDB (PK/FK) Concept
- Add a foreign key (FK) column such as
customer_idto the table schema, and the database ensures referential integrity. - Since relationships between tables are fixed at the schema stage, migration is required to add or modify relationships.
- While joins and constraints are powerful, they lack flexibility when connecting different modules or custom objects after the fact.
Comparison of Associations and RDB PK/FK
Perspective RDB PK/FK Sanka Association Unit of Design Table Definition and ID Column Association management function for records expanded with an intermediate table Addition of Relationships Migration Required Immediate reflection by creating a label from UI/API Connectable Target Fixed Two Tables Any standard/custom object, linkage of multiple tables, control function Integrity Assurance Assured by DB through FK constraints Logic control at the application/UI layer Definition of Relationship Meaning Dependent on column name (e.g., order_contact_id) Multilingual and context-specific naming provided by labels Search/Aggregation SQL JOIN as standard Extraction per label, with RDB JOIN or API processing performed as neededFrequently Asked Questions and Supplementary Information
Q. Is it necessary to enter the ID directly into the property?With associations, simply adding a record enables the creation of a new relationship. In contrast, in RDB, adding a foreign key necessitates schema modifications and migrations, making it difficult to quickly provide custom relationships for each client. Q. What is an association label?
A label defines what a particular relationship means and between which objects it is permitted. It centrally manages elements such as the display name in the UI, selectable targets, and one-to-many constraints. Q. How is data integrity maintained?
Instead of rigid constraints such as foreign keys in an RDB, integrity is maintained through application-layer logic. It is also possible to reset specific labels or enforce uniqueness constraints.
Summary
- Associations in Sanka are a mechanism that "expands and upgrades the relationships themselves."
- Declare meaning and constraints via labels and store specific pairs as records.
- As relationships can be flexibly reconfigured without schema changes, it is well suited for ERPs with many custom objects and external integrations.
