Your use case should not start from data stored, but from the queries
you want to search. Then you massage your data to fit that.
Don't worry too much about 'duplicate' too much at this stage. You
could delete the historical records if needed. Or index them without
storing.
What you should try to avoid is updating a record, as - under the
covers - a completely new record is created anyway. That's how the
search speed is achieved.
Regards,
Alex.
On 12 September 2018 at 16:10, Samatha Sajja
<samatha.sa...@samsclub.com.invalid> wrote:
> Hi,
>
> I have a use case where I am not sure which type of fields to use.
>
> Use case: For every order line we would like to store statuses and quantities
> For ex, I have placed an order with some item quantity of 6. 4 of them got
> shipped and 2 of them in processing. I would like to search on status and
> also need to know how much quantity is in that status
>
> Our current data model is for every order line. In the above scenario an
> order line can have multiple statuses and multiple quantities in those
> statuses. Don’t want to duplicate the data as it will update the statuses and
> quantity very often.
>
> Solution: Thinking of having a status:[SHIPPED,PROCESSING] and
> status_quantity:{"SHIPPED":4,"PROCESSING":2}
>
> Question: What is your recommendation? How should I define these fields?
>
> Regards
> Samatha Sajja
> Staff Software Engineer - TechCA
> Samsclub.com Engineering
> Location: 860 -1st Floor
> Email: ssa...@walmartlabs.com<file:///ssa...@walmartlabs.com>
> Slack: ssajja
>
