| Deletions are marked like this. | Additions are marked like this. |
| Line 25: | Line 25: |
|
Searching is a performance issue. Because of all '''[[Classifications]]''' are different records a large joins could be used to perform searching, which can be very slow. The following optimization steps will be implemented: 1. determine first the number of '''[[Classifications]]''' records involved in one aspect value search 1. perform a nested select with the smallest records set in the inner most level 1. read DrawingsRevisionsJoinSet with the where clause got from the select above E.g.: assumed that we are looking for documents with aspect codes 22, 345 and 42, the steps above: 1. `select code, count(*) from Classifications where code in ( 22, 345, 42 ) order by 2;` <<BR>> +------+----------+ | code | count(*) | +------+----------+ | 345 | 10 | +------+----------+ 1. `select objectId from Classifications where objectTypeId = ... and code` |
MultiClassification
Requirements
- unlimited number of classifications for one document (task)
- unlimited number of assigned aspect values in one aspect
Solution
Separate Classifications records are used for every classification which is set. No empty records used, a document has as many Classifications records as many classifications are set.
Detail
No problems determined until now. A smarty loop goes through all Classifications records to display them line to line.
New/Update
For every aspects defined in table Aspects at least one line appears even if it is empty. At the right side of all line there is a new button to open additional line for entering classification in the same aspect, and a delete button to remove that classification. If there is no more classification in an aspect (after deleting the last one) an empty line appears.
aspect X |
code |
AX_L1_0 |
AX_L2_0 |
... |
from - to |
new/delete |
|
code |
AX_L1_1 |
AX_L2_1 |
... |
from - to |
new/delete |
Search
Searching is a performance issue. Because of all Classifications are different records a large joins could be used to perform searching, which can be very slow. The following optimization steps will be implemented:
determine first the number of Classifications records involved in one aspect value search
- perform a nested select with the smallest records set in the inner most level
read DrawingsRevisionsJoinSet with the where clause got from the select above
E.g.: assumed that we are looking for documents with aspect codes 22, 345 and 42, the steps above:
select code, count(*) from Classifications where code in ( 22, 345, 42 ) order by 2;
+
+
+
- | code | count(*) |
+
+
+
- | 345 | 10 |
+
+
+
select objectId from Classifications where objectTypeId = ... and code
List
For performance tuning static database table will be used to store some information of classified documents:
drawingId |
aspect 0 |
... |
|||||
|
min code |
max code |
full code |
count |
from |
to |
... |