Lars Breddemann wrote:
Hi Jody
Fair point.
My angle towards the decision on the choice of development 'language' is a bit different here.
I tend to prefer solutions that are actually maintainable and I don't see that this is realistic with CE_-functions.
It just takes too much effort to get the syntax and table/field references all correct.
This is a good point. I have bad habit of referring to scripted CE functions, which indeed are less syntax-friendly than SQL. My intent though is to include graphical nodes in the concepts, which in my opinion are more maintainable than SQL. The case above (as with all cases except those requiring the almost-never-used CE_VERTICAL_UNION) could certainly be accomplished graphically. I'll try to be more conscientious about this with my comments!
While in SQL you can - at least partly - express intention and what data you want to see, CE_-functions force you to tell the database what to do and how to do it.
I wouldn't entirely agree. In both SQL and CE functions you express various operations like joins, aggregations, projections, etc. With SQL, every operation you specify is executed, albeit in some optimized fashion. With CE operators (graphically or functions), HANA will prune fields, joins, and branches where possible depending on the (resulting instantiated model which satisfies the) client query - which in my mind is more declarative in nature.
And concerning performance: I believe
(as in not tested recently) that mixing the operator classes still is not recommendable, agreed.
However, making performance decisions without measuring will lead to the wrong decision in 66% cases (the other being that performance got worse or that performance stayed the same).
And that is why I asked about the reason for the CE_-operator usage.
Sure. But given the graphical option - I'd say the right decision is made 66% of the time. (i.e. same performance with more maintainable model is the better option).
- Lars
↧
Re: Compare Timestamps of rows of the same table
↧