Wikka Logical Data Model
On this page I present a (half-way) logical data model for Wikka's data: an explanation of how the data "works" and a step on the way towards a better and expanded database.
Explaining the model to myself
On the WikkaPhysicalDataModel page I explained how I set out to make a model of the (current) physical data structure in Wikka's database and found I could not model all the relationships between the tables because the database is actually not structured to directly support the relationships that logically do exist between the data.So in parallel with creating the physical model, I created a logical one as well by "pulling apart" some tables that logically should be separate but (for unknown reasons) are not now. Adding some keys, and a field, and enlarging a few others, soon gave me a much better "picture" of how Wikka's data all hangs together.
The (sort of) logical data model
Actually it's not merely a logical data model - with the detail there is, it actually looks like a physical data model, only somewhat different than the current one. This is intentional: compared to the current physical model it's hypothetical (and hopefully clarifying) but at the same time this intended as a proposal for a future direction for our database. In my opinion this structure would not only be "cleaner" but would also support future expansion with new data types (tables) better. So here is a (slightly reduced) image of the"logical" data model. In the downloads section below you'll find a download link for the full-size image.
Downloads
You can also download aPlease make sure that the server has write access to a folder named uploads.
full-size version of the image.If you're interested in a more detailed look at the model, you can download
Please make sure that the server has write access to a folder named uploads.
the XML file with the model that you can load into DB Designer 4: it's a free application that is available for Windows and Linux, and released under GPL: well worth a look.--JavaWoman
CategoryWikkaArchitecture
Ownership history does not make logical sense to me. What does make sense to me is that a "page" is the whole thing, *with* its history, and that whole thing is "owned" by someone. That the current table may show different owners in different versions is IMO not intended, but merely an artifact of the way pages, their meta data *and* their history are now stored in a single table.
Well, I looked at how changing ownership is implemented in the code (handler acls calling the SetPageOwner() method in wikka.php. What this function does is *update* the *current* page version, rather than create a new version with new ownership. I can only interpret this as page ownership logically being tied to "page" rather than "page version".
So my conclusion is that my logical model above not only reflects what would IMO be desirable, but what is in fact intended with the way this functionality is coded.
The fact that the issue is confusing now because currently "owner" is stored in the single unnormalized "pages" table is all the more reason for making a split into a table for the logical page and a separate table storing its history, with owner tied to the "page" rather than a particular "page version".
(We could also add more features to the history like showing deleted pages in the "recentchanges [for what we would have to leave a "stump" of the page in the database] and an action like "Newpages", which list newly created pages)
"So the question is: do we need it?" Indeed. Nice for historians, maybe, but I don't really see any value in storing a history of ownership. Authorship is much more interesting - someone can be a page owner without ever contributing a snigle word.
"Deleted pages" and "newpages" would be possible without referring to ownership, of course; indeed for deleted pages there would then need to be some trace in the database, at least a "logical page" record; there is also Mike's idea of "hidden" pages (which would even keep a page's content to have an audit trail, just have it not visible for normal visitors).
Indeed, the "pages" submodel could do with some refinement. :) The idea is that the structure should support functionality, not make it difficult (and some things are difficult currently).
But this is only a small start...
But what about a interwiki table? (shortcut, url, description [,last_time_link_approved])? Would make it easy to manage the interwiki-list, but i fear there would be no real connection to the other tables.