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

[Michael Knoll]

Hi Franz,

perhaps one last tip: you could take a look at pt_gsashop which is 
available in TER and on FORGE. We have implemented scaled pricing 
according to the DB-schema of SAGE GS-Auftrag there. Perhaps you'll find 
a better solution there - perhaps not (the DB-Schema of GSA is not 
always state-of-the-art... but it's running).

Greetings

Michael




Franz Koch schrieb:
> 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.
>