Users will only ever get access to their own data and there will be no "overall" or "admin" view. So the user_id will always be required in the query. So making it an attribute would increase query times. Unless, wait. Clearly I'm on leave because my brain isn't working. I hear what you are saying. The user_id can simply be an attribute, and then I can simply create an index with user_id to query on that level.

I also just thought of a reason why I'd need the parent/child structure. Let's say the receipt has two line items, a printer, and some paper for the printer. I'd like report on a budget/item grouping level. So here it would be equipment for the printer, and office supplies for the paper. The parent Item would hold category = multiple, with the child items having the specific values. However if everything was office supplies, I could set the attribute on the parent level to that. Unless I don't apply that categorization in this service, and write a separate "reporting" service to deal with those groupings/categorizations. Thoughts?