Hi,
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.
-Yaron
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
