Is Hasso Plattner and SAP Correct About Database Aggregates?

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

Hasso Plattner and SAP made several statements around the necessity of removing aggregates.
In this article, we debate this claim.

Introduction

We debated the benefits of HANA aggregates with Vinnie Mirchandani.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

The Quotation

“It is fundamentally different. It streamlines your data architecture by not storing aggregate balances but calculating them as needed. It is memory hungry. However, it is another way to run enterprise apps. Same with Third Party Maintenance. Given the stubborn economics of IBM and Oracle in particular and the cost of DBAs etc, at least some companies are willing to consider them. My point is after 50 years we should be encouraging more companies to target the relational cost base. Oracle is trying to reduce the labor component with its autonomous features but wants to layer on its IaaS on top, not really improving the economics.”

Our Response on Aggregates

Vinnie,

SAP’s arguments around aggregates are entirely fallacious. We covered this in the following article. What is the Actual HANA Performance?

Let us ask the question of why SAP proposes removing aggregates. One reason is for compression. However, compression is only relevant because HANA is priced per GB. The size of the database does not matter very much. John Appleby back when he was the number one shill for HANA made the rather ludicrous statement that hard drives “take up space.” (we covered this ridiculous comment in the article How Accurate Was John Appleby on Moving BW to HANA.

I don’t have to tell you, that makes no sense. But SAP was doing anything they could to try to push the idea of reducing compression. Literally, no one outside of SAP or SAP mind controlled resources thinks who are riding the SAP money train that aggregates are a problem. There is simply no technical argument against them.

Literally no one outside of SAP or SAP mind controlled resources thinks who are riding the SAP money train that aggregates are a problem. There is simply no technical argument against them.

A second reason for emphasizing aggregates was to fake innovation. Our research shows that HANA is a type of fake innovation as we covered in How to Understand HANA as Fake Innovation.

Outside of removing aggregates and indexes, we can identify no other “new” items introduced by SAP. But the problem is that both of these ideas are pointless and would have only been proposed by a database novice. But remember, no one at SAP can tell Hasso he is unqualified to make such statements. And this is a primary problem with HANA. As I pointed out, HANA cannot meet its design objectives, because they were not realistic, to begin with. It was like Theranos, Elizabeth Holmes had no idea how to accomplish her objectives with the blood testing machine — she only had a hypothesis. And a hypothesis that ended up being false.

Elimination of aggregates is “not a thing.” Hasso had to say this was his contribution because he faked the origin of HANA as we covered in the article Did Hasso Plattner and His Ph.D. Students Invent HANA? Hasso does lacks the background to design a databases. So don’t take your information from him.

Your last point moves on to reducing the labor component of databases. Sure, that is fine, but again, that is not the primary focus of the beginning of your comment. I don’t want to address five different topics at once and do none of them proper service. This is exactly how Hasso tricks people, he keeps switching topics so nothing can be validated. If you feel confident on the topic of aggregates lets stick on that topic before saying that the real point is some other topic. Secondly, HANA is the most expensive database of any of the databases in TCO. So it is difficult to see where the economics argument holds water.

What you just wrote about aggregates is not correct, and it is boilerplate SAP marketing flim flam. This argument has already been broken into pieces.”

The Purposes of Aggregates in SAP

Aggregates had an additional purpose in SAP, which Rolf Paulson explains.

“Performance is one reason for the need of aggregates, but this is only needed for large tables. Many aggregates in SAP ERP exists because you simply cannot define aggregate views like SELECT SUM(…) FROM sales order GROUP BY department. Even if you have a table with let’s say several 1000 rows that any database just can aggregate on the fly and you want to show aggregates in a data grid, you must aggregate these data first with a stupid loop in ABAP. Just as recently as there are CDS views this is not necessary anymore.”