Changes between Version 33 and Version 34 of GenericTrac

Timestamp:

Aug 3, 2010, 6:52:34 PM (14 years ago)

Author:

Christian Boos

Comment:

requirement 3. (speed) ⇒ indexes

GenericTrac

@@ -95 +95 @@
 //seq// is the sequence number, which is used to support multiple values for the same property.
 
-Note by the way that newer "resources", like `repository` in MultiRepos already have this `(id,prop,value)` form, we'd only have to add `seq`.
-
-Note also that this sequence number could be a globally unique sequence number, which would make it possible to use it as a foreign key in specialized tables, in case properties are needed to describe the resource - property relation itself...
+Notes:
+ - newer "resources", like `repository` in MultiRepos already have this `(id,prop,value)` form, we'd only have to add `seq`.
+ - this sequence number could be a globally unique sequence number, which would make it possible to use it as a foreign key in specialized tables, in case properties are needed to describe the resource - property relation itself...
 
 ==== Schema
@@ -122 +122 @@
 
 This set of tables is a "generic scheme" that can be easily created for any kind of "resource". There's also a trade-off here, between using one very generic set of "resource_..." table versus special instances like "ticket_...": having one set of tables presents the risk of introducing too much contention for backends using table locking, and leads to writing queries that will contain lots of difficult to joins. We will already have enough issues with this when writing multicriteria search queries...
+
+For satisfying the requirement 3. (speed), we simply need to have enough indexes: 
+ - on `id`, for retrieving all properties of an instance at once
+ - on `(prop, value)`, for retrieving properties by values (searches and joins)
+
+I don't see an use case yet for indexing on `seq`, or to use other combinations.
+
 
 ==== Identifier