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.