[wp-trac] [WordPress Trac] #14558: Separate Database Table Support for Custom Post Types

[WordPress Trac]

#14558: Separate Database Table Support for Custom Post Types
-------------------------------+----------------------
 Reporter:  rahul286           |       Owner:  (none)
     Type:  enhancement        |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:  wontfix
 Keywords:                     |     Focuses:
-------------------------------+----------------------

Comment (by ReneHermi):

 > The post_type column is indexed, so I don't see unsolvable problems with
 export/import/bulk actions.

 Export/Import not but as you probably know we can not migrate and merge
 data from one site just in time to another due to shared data that should
 be separated.


 > Definitely plugin territory.
 > I can't see why core should support this, given the complexity with
 unique IDs that have to be solved.

 That's the point: Due to the given complexity with the unique UID
 we need to have a - preferably fully backward-compatible - API for CPT's
 for custom tables that can be used by every plugin. This should start with
 a plugin but it needs to get the full power and support of the core team
 like the Gutenberg project has.

 It's the core responsibility to show plugin developers the correct ways
 how to store data in a table.
 As the core was and as far as I know still recommends the use of CPT it's
 core responsibility to fix what it has been caused by this short-sighted
 implementation to denormalize the wp_posts table in such a heavy way.

 We need to work on this together and WordPress core needs to include the
 solution for storing custom post types in separate tables.

 Core and plugin developers need to pull the same strings and work on a
 common concept for reaching this. Otherwise, we will never be successful
 with storing data the right way as it is much too complex to solve without
 breaking millions of other sites.

 First of all we need to stop recommending the use of CPT's as they are
 immediate. WooCommerce is the best example: If they had foreseen that
 storing orders and customer data in _post/_postmeta makes it impossible to
 migrate staging/development sites they would never have done this.

 Now they are locked in technical dept as many other plugin developers as
 well.

 Having plugin developers storing all of their plugin data in CPT's in one
 table indexed by a global unifier was never the right decision in terms of
 good database design. It was a curse and a blessing. In the first years,
 we thought it was a good decision as it made storing data just simply for
 hobbyist developers and helped growing the WordPress ecosystem. Then it
 turned out that it led to the technical debt that we have today.
 Professional companies have a hard time to use WordPress because they are
 not able to easily migrate data from one test environment another.

 It should be especially in WooCommerce/Automatic intentions to get this
 solved as their users would benefit heavily from this. This issue can not
 be solved by a single person.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/14558#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform