Changes between Version 21 and Version 22 of GenericTrac

Timestamp:

Apr 13, 2010, 5:43:14 PM (14 years ago)

Author:

Christian Boos

Comment:

add a #RelatedProposals section and start discuss how MultipleProject would fit in the model

GenericTrac

@@ -12 +12 @@
    see [#RelatedTickets] for more)
 
+== Related Proposals ==
+
 This stems from the following former proposals:
  - TracObjectModelProposal
@@ -21 +23 @@
 As this will be a major redesign of the data model, 
 it could also be a good opportunity to take the 
-''[TracMultipleProjects multiple project]'' considerations into account (#130).
+**[TracMultipleProjects multiple project]** considerations into account (#130).
 
 Somehow related to the generic data model, but not strictly depending on it,
@@ -134 +136 @@
    - renaming is more difficult
  surrogate keys:: (''id'' would be a number in a sequence, never shown as such in the interface)
-   - only one type of keys (int) - faster, simpler, 
-     the unique ''resource_prop'' table approach is possible
-   - more compact, not that difficult to read either (there would always be a 
-     ''prop=id'', ''value=the natural key'' entry
-   - renaming is easy (relations preserved)
-
-This suggests that using surrogate keys would be preferable.
-
-
-Now if this is the case, the '''resource_prop''' table could as well become:
-||= id ||= prop ||= value ||= //seq//
-and the ''realm'' information could simply be stored as another prop/value entry.
+   - only one type of keys (int) - faster, simpler,
+   - the unique ''resource_prop'' table approach is possible
+   - more compact, not that difficult to read either as there would always be a prop/value pair (`'id'`,`<the natural key>`) 
+   - renaming is easy (relations are preserved)
+
+
+This all suggests that using surrogate keys would be preferable, with a single  '''resource_prop''' table.
+
+If this is the case, the '''resource_prop''' table could as well become simply:
+||= id ||= prop ||= value ||= //seq// ||
+
+ - the ''realm'' information could simply be stored as another prop/value entry (`'realm'`,`<the resource realm>`)
+ - this could be extended naturally to the ''support of multiple projects'', with another (`'project'`,`<projectid>`) prop/value pair; this is better as adding an additional `project` column to all entries
+
+Note that having a separate table for storing the ''relations only'' wouldn't necessary be better, as we would likely have to store something like:
+||= role ||= source ||= target ||= seq ||
+
+which is just a reformulation of:
+||= prop ||= id ||= value ||= seq ||
+
+i.e. the proposed '''resource_prop'''.
 
 
@@ -508 +519 @@
  - Data model issues: [[TicketQuery(status=!closed&keywords=~model)]]
  - Resource related: [[TicketQuery(status=!closed&keywords=~tracobject)]]
+