Thread:DoCheonGong/@comment-3225604-20160608091907/@comment-4189499-20160625131433

Regarding getting a true DBMS into this wiki: I've done a quick bit of research and found WikiDB and AccessPostgres. I don't really like the interface of the AccessPostgres option since it's not clear at what point the data is actually inserted into/modified in the database (on page save? On page load? Does the invocation create a button to be hit to write to the database? Do all rules have to be stored on a certain page? If I save the page a second time, will the modification happen again?). WikiDB does seem reasonable though. It doesn't seem very robust, as there's no formal definition of each table and you're relying on people inputting all their data correctly, but if we want to go with what seems to be an existing database system, that one could do. I mean, Python manages well enough as a programming language without formal variable declaration, but that sort of thing always makes me nervous. What do you think from your experience? Can you find any other options around? If we can find something that's flexible, fast, and easily edited by the average, non-technical editor, I definitely think it's worth investing in, it's just whether that option exists.

(There used to be a thing called Semantic MediaWiki which, from what I've read, acted a bit like a database, but Wikia had stopped allowing that extension to be enabled on their wikis due to performance reasons and unreasonable bugginess (read more here, especially the comment from DaNASCAT).)

If we were to go with our own solution, I think the best thing to do would be to simulate a bunch of JSON objects but with Lua. As Lua tables are hash maps, access is O(1), so it doesn't matter how big the tables get, and we can nest several deep without too much trouble. My worry with getting extra tables in to split up the data is that the extra access time jumping between tables, and going through the logic to decide which table to search, will cause more delays than just having all the data in one (or maybe two to separate Dreamworld and Reality) giant Lua table of tables organised first by episode, then level, then by different attributes. In terms of humans finding the correct sections to edit, if all the data is in one or two modules, they can use Ctrl-F to find the right part of the page. Anyway, it's not common for data to be modified after it has been inserted into the table, so as long as people can get to the end of the page easily to add new level information, I think we'll be all right.

As Lua isn't an actual database but rather a collection of objects, or at least tables which act as objects, we can nest heterogeneous data. For example, a timed level can store it's objective as 20 = { ...   type = "t", objective = 60, ...   } While an ingredient level can store its objective as: 12 = {   ...    type = "i", objective = { hazelnut = 1, cherry = 3 },   ...    } Knowing the type of level will then determine how the objective is understood, and as long as that understanding is the same for all levels of the same type, it doesn't matter that it differs between types.

For overall data layout design, I suggest the following: The information in the table can then be extracted from the table into a function like so: local example = reality["Candy Town"][levels][1][levelType] The information can then be looped over using a couple of nested for-each loops to get each episode and each level.

Methods can then be made to return all data, a single episode, a single level, or a single fact from the table, which should be flexible enough to cover most data extraction use cases. A separate module can then receive the data from this table and loop over it all to display the correct information in a table on the wiki itself for the list of levels pages, using if conditions to check if the data is, for example, an ingredient level to display on List of Ingredients levels. Areas such as the infoboxes can then query single facts about their levels to display to users rather than storing the information again on each separate page (causing data repetition problems).

While not as efficient or as flexible as an actual database, since it seems there's no obvious way to integrate, for example, a MySQL database into Lua that I could find in my (albeit limited) google searching, I think this could be a good compromise and worthy of prototyping at the very least. Can you think of any reasons why this wouldn't work, or have any suggestions to make it work better before I start prototyping? Again, even after all that, I don't know what effect creating the lists of levels from a Lua module would have on page load times (hopefully results would cache automatically, or we could even make a sort of "manual" caching through storing the results the first time a page is loaded in a day and just keep serving up that same string on any following page loads within 24 hours of computing the whole thing. It might be an idea to ask Wikia if they collect any stats on specific page views, and how often those "List of *" pages get viewed in a day/week), but if it's too slow (or even just doesn't work), we can fall back to your template option. The template solution would certainly be a lot less complicated once implemented to maintain!