Project Description
Without washrooms today, imagine what would human society be like? In the era of the proliferation of information, data is also need to be localized excreta, control defecation.
@@ -8,7 +18,7 @@
Instruction Set
There are 7 build-in wash instructions shown as following:
-
+
- The basic manipulation instructions mainly perform data isolation from source systems;
- The relationship clean-up instructions perform the waste separation.
@@ -17,7 +27,7 @@
- Face duplicate keys, none of them should be deleted physically. Instead, additional tags will be taken part in the discriminator to uniquely identify a business key. For example,
-
+
The duplicate key treatment is subdivided into two alternative methods:
- Check Unique Key (CHK_UK)
@@ -28,11 +38,11 @@
Face missing keys, all of supposed foreign keys should be made up in the primary table or bridge table if they were missing before, to avoid missing relationship. So that all subsequent users can consume the data straightforwardly and much more efficiently.
For example,
-
+
Wash Cycle
All 7 wash-instructions inherit from the base WASH_ISTR. They are organized under the wash cycle in sequence.
-
+
In many instances, developer may need to use individual steps for trial/debug convenience. Following diagram shows internal procedures of the whole build and deployment management.
(Labels in gray indicate the corresponding name of table, view, stored procedure or function)
-
+
@@ -519,7 +529,7 @@
in your seat or was generated in washroom.
Utilities by Product
All database packages of this project are organized in the package dependency graph below.
-
+
The bottom 3 blue packages PROGRESS_TRACK, DEPLOY_UTILITY and CACHE_UTILITY were designed to be used independently.
- PROGRESS_TRACK
@@ -600,7 +610,7 @@
CACHE_CONTROL is the central control table which defines a unique identifier and expiration for each cache.
-
+
The CACHE_UTILITY package provides a global cache control similar to
Reader-Writer Locks (refer to MSDN).
@@ -608,7 +618,7 @@
- Only work in critical period while cache expiring, as shown above.
- Only one refresher can obtain the token to exclusively access for refreshing, other blocked refreshers will not refresh again when they enter the lock, seen in the circuit diagram below.
-
+
- CACHE_UTILITY.ENTER_REFRESH_LOCK
- CACHE_UTILITY.EXIT_REFRESH_LOCK
@@ -648,7 +658,7 @@
Following diagram shown the internal implementation of cache lock mechanism.
-
+
In practice, a corresponding schema would be allocated for a cache to organize its target tables. This would help consumers to be clear which cache is using. Also combined with naming convention (E.g. suffix of schema name, prefix
of table name), whatever a schema contains a single cache or multiple caches ... all roads lead to a clarity, and reduce unnecessary configurations.
Risks of dead lock
@@ -775,7 +785,7 @@
- if the rest of safe period is not enough time to run related queries (estimation), then declines the human with message: "My cache system is busy in refreshing at the moment, please try again later. Sorry for the inconvenience, my dear!";
- else go ahead as you love at your own risk of data incompleteness in case your querying time runs too long (than estimated) to fall into crises... You should have a good sense of the result data is integral or not, so that you can retry later.
The view VPI.VIEW_CACHE_SAFE_PERIOD can be used to determine the safety, column names show as upper case in the figure below:
-
+
In order to make this option feasible, a higher level system plan may consider to preassign some consumers as female applications/reports with lock(period), other clients as male applications/reports without lock(period), ensure the cache will not be extinct.
@@ -790,7 +800,7 @@
Prevention over Treatment
Such note often seen in public washrooms:
-
+
(See: the Before and After
Triggers)
@@ -881,3 +891,5 @@
Welcome all feedback through the CodePlex project (through comments, patches, or items in the Issue Tracker);
Earnestly request adding implementation for other databases;
+
+