Page 1 of 1

A truly complex (in the mathematical sense) dependency graph

Posted: Thu Apr 26, 2018 9:06 am
by Schol-R-LEA
This thing is utterly terrifying.

Image

(Sorry about how big it is. Apparently, this version of PHPBB is too old to support image size limits - a feature introduced more than ten years ago...)

How do you get a dependency graph so complicated that it displays both a high fractional dimension and significant self-similarity? You know what, forget it, I don't want to know...

Apparently, this is an extreme example of softcoding gone mad:
Remy Porter wrote:What you’re seeing here is the relationship between stored procedures and tables. Circa 1995, when this application shambled into something resembling life, the thinking was, “If we put all the business logic in stored procedures, it’ll be easy to slap new GUIs on there as technology changes!”
The final paragraph is pretty awful, too:
Remy Porter wrote:By the time Thomas [a new developer on the project, and the person who submitted the story to The Daily WTF] came along to start a pseudo-greenfield GUI in ASP.Net, the first and simplest feature he needed to implement involved calling a 3,000 line stored procedure which required over 100 parameters.
I feel nauseated just reading that...

Re: A truly complex (in the mathematical sense) dependency g

Posted: Thu Apr 26, 2018 4:03 pm
by simeonz
Schol-R-LEA wrote:Apparently, this is an extreme example of softcoding gone mad
The article says:
What you’re seeing here is the relationship between stored procedures and tables.
This could, or rather should mean indirect relationship. Stored procedures can after all call other stored constructs. For example, I just checked (because my SQL is rusty and I was never a top dog) that inline table valued functions in SQL server are expanded in the outer query and have no detrimental impact on the performance and query execution plan. On the other hand Oracle's table functions are rigid - pipelining and multithreading is possible, but only when explicitly requested. That is, in Oracle, it appears that the table function crates a black box and a barrier for the optimizer. What I mean to say is that stored procedures need not be "softcoding" per se, depending on the technology you are given to work with. But apparently, their solution did not adapt well to its scale, for whatever reason.