Recently, the company responsible for the structural design of the database table unified user-centric, in the course of their work, the birth of a number of alternative ideas, especially to share it, looking forward to Paizhuan.
The evolution of thought is as follows.
The first stage:
The enterprises, institutions, families and other entities abstracted as "organization", Organization, referred to as "O", allowing multiple levels of organization, by parentId association;
The department and other organizations affiliated branch of abstract entities "Department", Department, referred to as "D", allows many departments parentId by association;
The natural entity abstracted as "natural", Human, referred to as "H";
Abstract "account", Account, referred to as "A";
Abstract "role", Role, referred to as "R".
Each organization can have multiple departments; every organization can have more than a natural person; every department can have more individuals.
Every organization, departments, individuals are allowed to have multiple accounts.
Accounts can be shared multiple roles.
The first phase relation shown in FIG ER
This is a very simple and clear model.
Unfortunately, the real world is not so simple.
second stage:
Through in-depth understanding of the products business, demand changed to:
An organization has multiple departments, but a department can belong to multiple organizations. (Example: two independently owned pharmacy chain, to share the same storage department.)
A department with more than a natural person, a natural person can belong to multiple departments. (Example: a department manager, general manager of the company, part of a number of important sectors.)
An organization with more than a natural person, a natural person can belong to multiple organizations. (Example: a doctor can be more practice.)
The second stage in FIG relationship ER
Now fairly normal.
The third phase:
Add a simple function - postal delivery address.
This is a simple feature, but the complication is that: the business, in the end is the "organization has a department has a shipping address shipping address shipping address or natural person has an account owned entities and receipt delivery address???? address, one to one or one to many relationship? "these questions, the product can not determine the direction of future extensions, you can only answer" are likely. " Haha. . .
According to conventional design methods, organization, between departments, natural persons, accounts and shipping address, between two add-many relationship table. The relationship between the number of tables begin to swell, as an orchard, the number of weeds to be more than the amount of fruits and vegetables. . .
In order to reduce the number of weeds, abstract design of a weed:
Add relationship entities (organizations, departments, individuals, account) and postal address, by an entity with an enumeration code values id two entities, the real decision entity; postal delivery address Id, decided to shipping address.
E.g:
Entity enumeration code O, entity id 1, id 10 postal delivery address, expressed: id for an organization 1, with id 10 for a shipping address.
Entity enumeration code H, entity id 2, id 20 postal delivery address, expressed: id 2 for a natural person, with id 20 for a shipping address.
Entity enumeration code A, entity id 3, id 30 postal delivery address, expressed: id for an account 3, with id 30 for a shipping address.
The third phase relationship shown in ER
The fourth stage:
At this time company executives to join the discussion needs,
A, control particles of the required data should reach a single data and relationship data may be in accordance with any outside entity, authority control, but the specific needs of the indefinite, required to do the maximum design flexibility.
B, an additional qualification management, valid management functions, business also do not know what the future direction of expansion where required to do maximum design flexibility.
As a result, the number of abstract weeds began to swell up.
Demand for A, designed OneId table, Id backup of all entities in the table, the future, once the data row-level access control, the relationship expanded by OneId table.
And to make abstract weeds number does not expand, the universal design table, designed as follows:
| Universal table | |||
| Entity enumeration code | Entity Id | Entity enumeration code | Entity Id |
For example
| Universal table | |||
| Entity enumeration code | Entity Id | Entity enumeration code | Entity Id |
| O | 1 | H | 10 |
| O | 1 | H | 11 |
| H | 10 | A | 100 |
| H | 10 | A | 101 |
Above data, is described
"Id 1 for an organization with an id of 10, 11 of two natural persons";
"Id 10 for a natural person, with an id of 100, 101 of the two accounts."
Any complex / undetermined many relationships, can be described by this universal table.
The final version of the entire database design changes:
Note: No matter how the future business expansion, how the relationship changes only need to be extended to the new entity, need to consider relationships with other entities, the history of design will not have any impact.
This is a departure from all existing paradigm of database design, database design simple and universal method, Universal DB Design Method, UDDM, it referred to the method of Judah, I feel very appropriate.
The above design method, my team has not enough internal capacity to judge right and wrong, we look forward to actively Paizhuan to explore.