[TYPO3-mvc] Best practice for a domain model for scaled prices

[Franz Koch]

Hi Michael,

>> So I was thinking about dropping the "basic price" from
>> tx_myExt_domain_model_price and create it as record with the quantity
>> 1 in tx_myExt_domain_model_scaledPriceValues. Does this still sound
>> good to you?
>
> That sounds much better to me than your first approach. It will be more
> consistent and less error-prone (think about updating prices, which will
> have to be done at 2 places in your first draft!).

Thanks for sharing your thoughts. That's how I started implementing it 
by now - at least on DB level and in TCA so far.

> Maybe I should rename the scaledPriceValue then to
>> tx_myExt_domain_model_priceValue or something, but I fear the
>> resulting queries with joins over several mm-tables will become a
>> performance killer, too.
>>
>
> I actually don't think so. There will be a join of 3 tables:
>
> article->price->scaled_prices

well yes, while I could at least use the joins over several mm-tables 
for sorting, the process for fetching the actual objects for displaying 
scaled prices is triggering at least one additional query per article on 
using a intermediate price object. But I'll see how this turns out 
performance wise.

> That sounds quite easy for me. Perhaps you could introduce a field
> "standard_price" or "sorting_price" on the "price" object to be able to
> apply any field you wish as a sorting indicator. This could prevent a
> subselect on the scaled price table to get a - what-so-ever-looking -
> price for sorting. I'm not sure, whether this was the "basic_price" in
> your first draft... if that's what you wanted to do with it - I would
> still do so.

yes, the "basic_price" should have been the default price for regular 
sorting etc, but as it might also happen to search for and sort by the 
cheapest price possible, scaled prices could also come into place for 
those actions. But with the concept you also suggested this isn't a 
problem anymore. And the default price is always the one with the 
quantity "1" - so no extra property necessary either. I think that's the 
best way doing it.

> Another idea could be to use a price-property on the article. Not for
> returning any prices in the frontend but just for sorting. This could
> prevent you from doing any joins when sorting a list by price.

that won't work, because the general pricing can change depending on the 
catalog and the client selected in FE.

> I hope my thoughts could help you a little!

yes, thanks a lot.

-- 
kind regards,
Franz Koch

---------------------------------------------------
PayPal-Account: 'paypal _at_ elements-net _dot_ de'
---------------------------------------------------