SMW now has about 28+ db tables, yes you heard it right and that’s where my bragging rights for DB Sharding comes from 😉 , read ahead to know more –
SMW now has about 28 db tables, this has been a major uplift from what we had initially. The more tables we have the less things to load into memory at a time, lesser storage requirement (no foreign keys) and faster querying (again no foreign keys to compare). Plus there’s an awesome feature that lets you to shard the db even more (the + in 28+), you can assign separate tables for each of your property (yes, you-the admin can control it now 😉 ), this is suggested for properties that are highly used in your wiki (now don’t you worry how to figure this out yet), This way you can have up to as many tables as you want. But still beware there might be bugs to fix.
Ok, now back to how do you know what properties will be used extensively in the future? this can be an estimate, say a property email is more likely to be used extensively so it should be marked as a fixed-property (yet to document on this stuff). But if you don’t want all this gibberish you can mark a property as fixed-property even when its in use, but then you would have to run a SQL script after that so your site can work perfectly ok (Btw this script is yet to be created, but is rumored to be fairly simple to create)
Ok, now the testing part. I have done some intensive testing using my own written tests for SMW plus on a local wiki (which has a massive import from semanticweb.org) and bugs are identified mostly but there might be a few of them still hiding for you. If you are reading this and want to help us to test stuff please do it! All you need to do is setup a local wiki with SMW installed (do check out from the master and then make the default store SQLStore3) then import from a highly used SMW wiki (which I assume you own if you have read this far :P) and then after the import is done run a refresh.php to refresh all your SMW content. After that I know you are gonna comment here about the bugs 😀