Thread:Talk:Requests for comment/New sites system/Database schema proposal/reply (2)

It's missing the type and group being varbinary instead of ints as was said to be fixed there. Also the dropping of site_file_path. However I still don't like the site_url and site_page_path separation. IMHO the actual url still looks like type specific data.

Btw when I said "Do we want to split the data into two different tables?" I was mostly serious with that as a question. I haven't quite figured out if that's a good idea or not. The one technical reason to do that I can think of would be to share the database. But when I think about it again trying to manage it in that situation where a tiny change on one wiki suddenly affects every wiki makes me think things could quickly go wrong. So I don't know which is the option to use yet. We also need to have a separate discussion on whether the site table is going to be a first-class table of data or an index built up of configured sources. That decision will probably also affect what we do in this part of the schema.

Notes on sitelocal:
 * Presumably sitelocal is a multi-row 0+ table. Do we need link_inline anymore? Is there actually a situation where we can have an interwiki prefix and have it be a language link but not be an interwiki link?
 * Also sitelocal_config. Do we really want separate site config for each prefix? ie: If Asdf: and en: point to the same site, is there any reason only one of them should be usable in interwiki transclusion?
 * If we can't come up with a use for it I'd like to avoid having the table storing our prefixes have extra data besides the flag that says whether if the prefix is an interlanguage. The UI for separating interlanguage and interwiki links is one thing. For that we would just let the user input a comma-separated list of interwiki prefixes and a separate box would have a comma-separated list of interlanguage prefixes. But if we add any more data than that to the prefix the UI suddenly explodes from just editing a simple form of site data to something with subforms containing configuration for every single prefix.