Difference between revisions of "IdColumnReasons"

Jump to: navigation, search
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
Apache JMeter  is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
+
{{obsolete}}=Reasons=
 +
There are was many "holy wars" about making additional surrogate key (id column) when "real" PK is can be combination of some FK in the table
  
There's a place in Moodle Contrib for people to share their Jmeter scripts here:
+
==first (not main) reason:==
http://cvs.moodle.org/contrib/tools/jmeter/
+
:But problems arrive when any of the get_record_XXX() functions are used, because all them returns associative arrays (GetAssoc()) where the first field in the returned recordset becomes the key of the array. So having those artificial "id" fields for each table is the only mechanism to fetch all the records from any table without losing some of them by the "key overwritten" effect. Following your example, something so simple like:
  
For more information about JMeter and what it could help you to stress test your Moodle installation, please see:
+
:get_records('user_teachers')
http://jakarta.apache.org/jmeter/
 
  
For JMeter FAQ, see:
+
:won't work if the id field is missing. Only one occurrence of every teacher (the first field in the select, userid) will be returned, missing a lot of records.
http://wiki.apache.org/jakarta-jmeter/JMeterFAQ
 
  
==See also==
+
:I'm pretty sure that we could bypass this limit in the long term (current recordsets implementation is a good start) but it would force us to review all the get_records_XXX() calls before, because a lot of them, simply will break and others could be using the GetAssoc() key feature in its own benefit so, modifying the type of arrays returned by the functions isn't an immediate alternative.
*[http://moodle.org/mod/forum/discuss.php?d=119443 Using Moodle forum discussion on Jmeter Scripts]
+
(c) [http://moodle.org/user/view.php?id=3176 Eloy Lafuente (stronk7)]
*[http://www.open.ac.uk/blogs/XHProf/?page_id=64 JMeter testplan generation Moodle plugin] developed by [http://moodle.org/user/view.php?id=264538&course=5 James Brisland]
+
==next reason (? - peoples, add more reasons!)==
*[http://www.javapassion.com/handsonlabs/javatestjmeter/index.html JavaPassion LAB 1077: JMeter Load Testing]
+
=See also=
 +
==Moodle links==
 +
* [http://moodle.org/mod/forum/discuss.php?d=38183 General developer forum » Important! insert_record() changes]
 +
* [http://moodle.org/bugs/bug.php?op=show&bugid=4583 Bug #4583 - hotpot doesn't restore]
 +
==External links==
 +
* [http://www.datawarehouse.com/article/?articleId=3103 Modeling Matters: The Semantics of Surrogate Keys and Business Keys, Part 1]
 +
* [http://www.datawarehouse.com/article/?articleId=3113 Modeling Matters: The Semantics of Surrogate Keys and Business Keys, Part 2]
 +
* [http://www.dbmsmag.com/9805d05.html Surrogate Keys: Keep control over record identifiers by generating new keys for the data warehouse]

Latest revision as of 13:00, 10 November 2013

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

Reasons

There are was many "holy wars" about making additional surrogate key (id column) when "real" PK is can be combination of some FK in the table

first (not main) reason:

But problems arrive when any of the get_record_XXX() functions are used, because all them returns associative arrays (GetAssoc()) where the first field in the returned recordset becomes the key of the array. So having those artificial "id" fields for each table is the only mechanism to fetch all the records from any table without losing some of them by the "key overwritten" effect. Following your example, something so simple like:
get_records('user_teachers')
won't work if the id field is missing. Only one occurrence of every teacher (the first field in the select, userid) will be returned, missing a lot of records.
I'm pretty sure that we could bypass this limit in the long term (current recordsets implementation is a good start) but it would force us to review all the get_records_XXX() calls before, because a lot of them, simply will break and others could be using the GetAssoc() key feature in its own benefit so, modifying the type of arrays returned by the functions isn't an immediate alternative.

(c) Eloy Lafuente (stronk7)

next reason (? - peoples, add more reasons!)

See also

Moodle links

External links