Difference between revisions of "IdColumnReasons"
(Created page with "=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...")
Revision as of 08:42, 16 June 2011
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:
- 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.