Talk:Requests for comment/Associated namespaces/Database schemas

marktraceur's notes

 * A namespace can be defined as the lead namespace of a group of namespaces

Why? Why not just define a namespace and then relations to other namespaces? That way you can remove the ns_talk_of field, and probably ns_type. You replace them with a table that looks like so:

I'd do something like this:

The nice thing about this approach is that you can have multiple "talk" relations without issue, and also you can have multiple other relations easily. One possible issue is that there can be multiple talk pages for the same one page...this may be useful, though, if there are different kinds of discussion you want in a namespace...anyway, I see no reason to have a "lead" namespace, or "groups" - they can just have relationships. --MarkTraceur (talk) 22:05, 24 April 2014 (UTC)


 * Let me see if I understood your example:
 * if I create a new page in page namespace 16, I can have one associated page from ns 10
 * if I create a new page in page namespace 11, I can have one associated page from ns 10, 16 and 17
 * When checking which relations has a page from ns 10 to other namespaces, how can I know if it is associated to just ns 16, or to ns 11, 16 and 17? How would you check for inconsistencies?--Micru (talk) 06:20, 25 April 2014 (UTC)
 * OK so.
 * In the current system, every page *has* a talk page. In a new system, every page that had a relationship to another namespace (e.g. Template, Template_Talk, Template_Documentation, and Template_Data in the above example) would have all of the related pages already, they just might not exist. So when I go to a Template page, there's a SELECT statement (heavily cached) that asks "What namespaces are associated with this namespace?" and then those tabs get created in the interface.
 * The enforcement will come in when people try to add multiple relationships to different talk pages for the same namespace, IMO. Enforcing one of each type of relationship per namespace might be nice, and you might accomplish this with a finite set of table fields, but we could as easily and more extensibly accomplish it with a table and appropriate uniqueness checks. --MarkTraceur (talk) 16:02, 25 April 2014 (UTC)
 * Ok, that makes sense..then I'll update the table as you said and I'll keep asking for feedback.--Micru (talk) 17:14, 25 April 2014 (UTC)

Indeces nl_namespace_name vs. nl_namespace_default
AFAICS nl_namespace_name and nl_namespace_default duplicate each other in function; why not just drop nl_namespace and use nl_namespace_default as both the constraint and primary key? (It's been a long time since I did anything proper with DB performance, though, so not sure what the performance impact would be here.) Jdforrester (WMF) (talk) 17:59, 25 April 2014 (UTC)

semi-CSV? + My old schema
What is with the weird custom "semi-CSV" format? Custom data formats are never a good idea for something like this, we don't want custom parsing and serialization code for this, please just use json or php's serialize format. This one-level semi-CSV also looks like a bad idea since it appears this schema has separate ns_protection and ns_options, if the schema used json or serialize there would be no need to have two columns for settings.

I did some experimentation with namespace registration before, take a look at the schema I used: https://github.com/dantman/mediawiki-core/compare/master...namespace-registry#diff-a22af9c6d1b8ab836a50a290227b98c9L1489 ~ Daniel Friesen (Dantman) (talk) 22:24, 25 April 2014 (UTC)
 * I merged nw_protection and nw_configuration into ns_settings as you suggested. Could you take another look and modify it as you feel convenient? --Micru (talk) 13:07, 28 April 2014 (UTC)