Separation between contents and system tables

  1. Andrea Sciamanna

    I think that the ability to have two different wordpress databases could help for at least two scenarios:

    • Easy migrate contents from different environments (development, test, preproduction, production), especially during a first development-release process. This would allow to export all wordpress system tables between each environment, leaving content's tables untouched
    • Better separation of the most important data (contents) with the ability to keep them in different servers

    Of course this would be an optional feature, as no everyone can have more than one database.

    But I wonder, since this has been never done, maybe I'm missing something?

    Posted: 5 years ago #
  2. Ipstenu (Mika Epstein)
    Lead Plugin Wrangler

  3. Andrea Sciamanna

    Ipstenu, thank you!

    It looks interesting, however this plugin is quite expensive and has some limitation.

    My idea is a bit simpler also to implement from the WP team, I believe.

    Two databases: one for all contents related tables (posts, posts meta, comments, taxonomies, terms, etc.) and one for the system tables (options, users, usersmeta).

    Just that.

    Posted: 5 years ago #
  4. Ipstenu (Mika Epstein)
    Lead Plugin Wrangler

    It's probably not going to happen any time soon.

    Also, you'd be best served by letting go of the notion that things are 'best' done by the WP team :) The work of the rest of us is as much a part of how WP improves, and MANY things start out their lives out in the wild.

    Posted: 5 years ago #
  5. Andrea Sciamanna

    Is not going to happen at all if nobody ask first.

    About "letting go of the notion that things are 'best' done by the WP team" I may agree, but then what would be the point of space?

    Posted: 5 years ago #
  6. Ipstenu (Mika Epstein)
    Lead Plugin Wrangler

    It's not that no one asked. Its ... well.

    You CAN split your database exactly as you described. In fact, people do that for Multisite all the time. The PROBLEM is it involves a degree of DB knowledge, that no code can really automate well. And it's not really the way WP was designed to work. Besides, a lot of hosts limit you to ONE database. You've just cut them out of the ability to do WP.

    Look up SharDB and HyperDB. Database stuff gets complicated fast, and MOST people don't need it. It's the 80-20 rule at play. Those who DO need it need a solution very specific to their needs. There's no good general 'this will work for everyone!' answer any more than there is for, say, backups. That's precisely why this isn't in core. Too many options.

    About "letting go of the notion that things are 'best' done by the WP team" I may agree, but then what would be the point of space?

    You mean 'what's the point of THIS space'? To make suggestions. But ALSO to accept that sometimes, the answer is 'no' or 'use a plugin' :) or 'NOT in core.' Those are acceptable answers.

    Posted: 5 years ago #

RSS feed for this topic


You must log in to post.

  • Rating

    0 Votes
  • Status

    This is plugin territory