Why not shifting away from posts table?

[RobertMPop]

While I was aware that the custom products table plugin developed by the Woo guys only moves the data from the postmeta table into a main flat table + a few other tables, I was somehow expecting that your plugin will not be half-pregnant as well.

Can anyone please explain why you guys are not developing this by completely separating the orders from the WP's standard posts + postmeta? Meaning that the orders (and products) should be redesigned as stand-alone, thus also moving away from the posts table, and not just from the postmeta table.

Sure, I totally understand that this means a good amount of some extra, hard work. But you have embarked in long-term projects and, since you are already at it, why only going half of the way?

I'm just trying to understand.

[marcusquinn]

1. Compatibility with almost any other plugin.
2. Post tables are designed for fast reading and flexible development without requiring SQL updates.
3. Flat tables take up more disk-space with reserved space for empty fields, EAV tables don't.
4. Cost/benefit whereby this creates more complexity and cost where there are far bigger wins available elsewhere.
5. You can find more Woocommerce performance and scalability improving ideas here:
   • https://www.wpintense.com
   • https://foundthru.com
   • http://brandlight.org

[stevegrunwell]

Hi @RobertMPop,

I absolutely get where you're coming from, though it's important to remember that WooCommerce as a platform is built atop WordPress. The CRUD APIs that were introduced in WooCommerce 3.0 have gone a long way towards making WooCommerce more flexible with regards to data storage, but at the end of the day, "product" and "shop_order" are both custom post types in the eyes of WordPress.

Products, orders, et al being custom post types provides a number of advantages:

1. We're able to use the existing DBAL, accessing these objects via WP_Query rather than reimplementing everything.
2. Deep integration with WordPress, including edit screens, rewrite rules, capability checks, menus, and more.
3. The ability to extend these post types with custom post meta; in both the Custom Product Tables and Custom Orders Table extensions, we're able to store the most common meta in a flat, well-indexed table, while letting custom meta be used as necessary.
4. As @surferking noted, keeping products and orders as custom post types grant us compatibility with both WooCommerce extensions and general WordPress plugins.

If WooCommerce were being built from scratch today, there's a good chance the data structures would look very different, even more so if it was being built as an ecommerce platform independent of WordPress (for example, BigCommerce). As it stands, WooCommerce is the leading ecommerce plugin built on top of WordPress, so aspects of the underlying architecture are dictated by that underlying platform.

Hopefully that clears up any confusion!

[marcusquinn]

It's absolutely possible to make large and scaleable ecommerce websites with WooCommerce too and we've done just that with all these sites:

https://brandlight.org/i/partnerships/clients/

It has however taken a team of 20 developers and 3 years to get that level or performance, scale and multilingual showing off, so we're well aware how difficult it is with the basics and wanting to focus more on content and business than development.

If we weren't such a team then I'd 100% recommend you look at https://odoo.com either Community or Enterprise depending on your team and needs.

Otherwise, we're aiming to open-source the whole Brandlight stack one day to show that we can beat any platform on any metric, and it has nothing to do with flat vs EAV tables - but right now I have to focus on the businesses behind those websites so hopefully you have some options and insights at least from your good question.