Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"A basic installation of SAP has 20,000 database tables, 3,000 of which are configuration tables. In those tables, there are ~8,000 configuration decisions you need before even getting started."

Wow, really?



He's conflating SAP (a company) with the ERP system, but reality is a little different. There are 133,000 tables in a system I just checked, and 40,000 are flagged as configuration.


Sounds like a perfectly cromulent database.


What's the breakdown of those configuration tables? I'd imagine (perhaps incorrectly) that most are just integer/enum/bool fields?

If so, how many of those tables just exist to define enumeration cases?


I suspect an awful lot. I worked at a place that did their own ERP software and that had thousands of database tables, many of which were simply enum fields.

The entire system required magic numbers to be put into various columns in different tables, simply to modify the behaviour of the "logic" code as it resolved to a C++ enum once extracted from the database.

It was horrible, and nobody knew how the entire system worked, so there was a vast disconnect between what it actually did (and the hundreds of auto-generated SQL statements it ran, very slow) and what they thought it did.

As expected, this created wildly different expectations of what was possible from the internal "implementation" team versus developers. Of course, this was interpreted as the developers' fault, and there was a constant stream of new developers that would stay for a year or two, then leave. Toxic.


Configuration is still data... If by "to define enumeration cases" you mean lookup tables, they exists to ensure data integrity.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: