| 414 | | |
| 415 | | - '''Comment''' Why not implement all of the different resource_prop* tables into a single table, where each tupel has multiple attributes, see for example the JBPM datamodel for a working and presumably also fast approach. Here, there exists a process_variable or some similar table that stores all the different value types in single table. And please rename the ''name'' field to ''prop'' so that it matches the one in the resource_schema table.The schema would be like so: |
| | 414 | '''Comments''' (cklein) |
| | 415 | - Why not implement all of the different `resource_prop*` tables into a single table, where each tupel has multiple attributes, see for example the JBPM datamodel for a working and presumably also fast approach. Here, there exists a process_variable or some similar table that stores all the different value types in single table. |
| | 416 | - (cboos) not sure how you see that as an advantage; each row will waste all the fields but one; there need to be one index for each type, each index having to deal with lots of NULL values, each update will have to rebuild all indexes, etc.). But it could be worth benchmarking anyway... |
| | 417 | The schema would be like so: |
| 449 | | |
| 450 | | - '''Comment''' Also I would like to have the resource_schema table extended so that it will support different schemas for, say, different ticket types. That way, users can define their personal ticket type schemas. Of course, derivation would also be nice, but that could be implemented at a later point in time, requiring yet another table. That way we could have both inheritance at the schema level and also multiple different models per realm ;) |
| 451 | | |
| 452 | | |
| | 451 | - And please rename the ''name'' field to ''prop'' so that it matches the one in the resource_schema table. |
| | 452 | - (cboos) will do |
| | 453 | - Also I would like to have the resource_schema table extended so that it will support different schemas for, say, different ticket types. That way, users can define their personal ticket type schemas. Of course, derivation would also be nice, but that could be implemented at a later point in time, requiring yet another table. That way we could have both inheritance at the schema level and also multiple different models per realm ;) |
| | 454 | {{{ |
