Is your feature request related to a problem? Please describe.
EcomOrders is currently storing data for multiple types of objects (Carts, Orders, Quotes, Ledgers and Recurring Order templates). And in some custom scenarios we tend to also import into these tables (because the data model is very similar).
From the data model point of view this is mostly acceptable (despite some fields and custom fields are only applicable to some).
What we're experiencing is that we have a major difference between Carts and all others:
Carts (and maybe Quotes) tend to be write intensive (because they are updated frequently (until they become an order or are abandoned)
All other objects are written once and updated once or twice (state update, track and trace number update)
This makes indexes a bit harder, because they become more easily fragmented and/or the approach becomes different (i.e. non-clustered vs clustered indexes)
Describe the solution you'd like
Just looking from this angle, the solution seems to be to have tables just to handle Carts vs everything else. And maybe even consider which objects should live in separate tables.
Describe alternatives you've considered
None for the standard things
For custom objects, we discussed whether to keep using EcomOrders (adding custom fields to handle something like a LedgetSubType) versus using custom SQL tables (which then forces us to use Data Lists or Query publisher)
Additional context
This topic was discussed with Jeppe at the Summit. We know it's not an immediate solution; it's an observation of real-world use cases.
Is your feature request related to a problem? Please describe. EcomOrders is currently storing data for multiple types of objects (Carts, Orders, Quotes, Ledgers and Recurring Order templates). And in some custom scenarios we tend to also import into these tables (because the data model is very similar). From the data model point of view this is mostly acceptable (despite some fields and custom fields are only applicable to some). What we're experiencing is that we have a major difference between Carts and all others:
Describe the solution you'd like Just looking from this angle, the solution seems to be to have tables just to handle Carts vs everything else. And maybe even consider which objects should live in separate tables.
Describe alternatives you've considered None for the standard things For custom objects, we discussed whether to keep using EcomOrders (adding custom fields to handle something like a LedgetSubType) versus using custom SQL tables (which then forces us to use Data Lists or Query publisher)
Additional context This topic was discussed with Jeppe at the Summit. We know it's not an immediate solution; it's an observation of real-world use cases.