I'm finally trying out SMWSQLStore3, and figuring out how to get my extensions compatible with it, so I'm looking at the new table structure for the first time.

First of all, is there any documentation about the design decisions that went into this new structure? Because it could be that this issue has been answered already.

If not - basically, the way the new database structure seem to work is that there's a separate table for each special property. "Creation date" and "Modification date" both have one, as do "Has improper value for", and probably some others. Interestingly, there are also tables for the Semantic Forms special properties "Has default form" and "Has alternate form".

This strikes me as strange design, for a few reasons:

- I assume that this is done to speed up querying; but, as far as I know, many of SMW's special properties - like "Creation date" and the rest - are rarely queried on.

- This could lead to an explosion of database tables - it looks like there are about 30 in the new structure, which some might consider an explosion already, and if there are a bunch more special properties added for metadata (like "last author", "first author", etc.) the number could just keep growing indefinitely.

- It's understandable that Semantic Forms would get special handling, but still, having one extension handle things for another introduces dependency issues. What if Semantic Forms got other special properties? Or what if, say, "Has alternate form" were removed? It could potentially lead to compatibility problems.

- On that note, SF already has two special properties that don't have their own table - "Page has default form" and "Creates pages with form", both of which can apply to forms just like "Has default form" and "Has alternate form" do. Not that I'm suggesting that SMW should get two more tables for these, but on the other hand, I believe SF queries on these on a fairly regular basis.

So what could be done instead? I can think of a few options:

- Store all properties, special and otherwise, in the same set of tables, and make better use of indexing to speed up queries.

- Create tables for general use by all special properties. In the new design, SMW has a separate table for each property type, but for special properties I think there are really only three types that have been used: "Page", "Date" and "String". So it could be that only three special property tables would be required. Again, indexing could be used here.

- If Semantic Forms specifically is slowing things down with its querying, maybe that extension should change its own handling. It doesn't necessarily even need to use SMW to store information on "Has default form" and the rest - it could use the standard MediaWiki page_props table. SF's special properties are never queried on alongside regular properties, so I don't think that would have a negative impact on users. That could be fairly easily done (although the use of SMW would be preserved for backwards compatibility, probably with the aid of a LocalSettings.php setting). I don't know if that would improve performance at all, but it might be worth trying out.

- For that matter, maybe many of the other special properties could be stored using the page_props table instead. SMW has always been used to store metadata just because it was convenient to do - but if that storage is leading to significant performance problems, maybe page_props is the faster and (at least to the extent that it reduces table clutter) easier alternative.


WikiWorks MediaWiki Consulting http://wikiworks.com