SQLStore update/Tasks

Phase-1 Tasks

 * Sketch main workflows for update and data access with the new storage architecture. Find out which methods and which descriptions (of tables) are required.
 * New property_id table. Properties use the same ids whether used as properties or as pages (subject/object)
 * property types would be stored in a special table with at most one type per property
 * Properties needing a special table will be defined in LocalSettings.php. It can be enough to list the property names; the store can then create a table name from the property name (using a hash on the property name).
 * Have an internal mechanism for using special tables for some properties. Use this for some internal special propeties (the necessary tables can be created on setup).


 * There could be a table for storing the whole data of one subject as a blob. This could speed up getSemanticData (without filter) and getProperties. One could have this as an optional feature that can be enabled in configuration.
 * Check why editing a page and saving it without any changes still triggers SMW storage code, and fix it.
 * Store an array of hashes for each subject and table (use a serialised array "table"=>"hash" blob for this). Filter updates (delete and write) using these hashes.


 * For the moment, do not touch smw_redi2, but do not consider it as a property-value table. It can be ignored in all normal data access methods.