Changes between Version 7 and Version 8 of TracDev/Proposals/DataModel
- Timestamp:
- Feb 24, 2010, 8:22:23 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/Proposals/DataModel
v7 v8 25 25 Then, each resource should have a `<resource>_prop` table, which can be seen as a generalization of the `ticket_custom` table we have now. I think it's enough to have `(name,value)` columns, however, as the type information could eventually be stored in some `resource_schema` table. 26 26 27 - '''Comment:''' I think that this scheme should be generalized so that there is only one prop table, with provably also more specialized prop tables for the various datatypes. However, this would require a resource_type and a resource_id attribute so that selects will work as expected. Since building queries that would get an object's state in one single query is quite tough, this should be a two stage process, first the resource and then the properties of that resource using unions.28 29 27 Also, it might well be that we'll actually need to have datatype-specific property tables, like `<tesource>_prop_int`, `<resource>_prop_text`, even `<resource>_prop_resource` for linking to other resources in a flexible way (TracCrossReferences style). 30 28