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

Course I'm still not keen on the site_url/site_page_path separation an think it should be type data.

In order to be able to make a link to a site, we need to know where to put the page name. In the current interwiki table this is done with a single field holding for instance. I've now split this up into the base url and the part being appended. I don't see how this is type specific. It's true that the part being appended has a typical format per type, and often even tends to have the same value per type of site (ie /wiki/ suggests MediaWiki). But those are the values of the field being type specific, not the field itself.

I'd be great to find an approach with which we're both happy ofc - I'd love to see a suggestion coming from you. Just moving the field into ALL of the type classes would be rather stupid obviously (and makes it apparent it's not type specific), so that's not an approach I could settle for.

I think we can drop site_link_inline.

Definitely, gone now :)

site_global_key can probably just be site_global, or maybe just site_key since we're already talking about the unique data

Disagree - the current name is clearer, and the 4 extra bytes are not going to kill anyone. site_global could be confused with a setting indicating if it's a global site or not (ie you just wasted a minute of every new dev looking at the code).

For si_site_id using si_site would match the other tables, see rev_page.

You're right, did not know of this "convention". Updated now.

si_key_type can probably be just si_type.

Yeah.