Jump to content


Photo

I Guess Size Doesn't Matter


  • Please log in to reply
8 replies to this topic

#1 BrewerGeorge

BrewerGeorge

    His Royal Misinformed

  • Administrator
  • PipPipPipPipPip
  • 32085 posts
  • LocationIndianapolis

Posted 13 June 2019 - 06:14 AM

This is for the computer guys.

 

I'm overseeing a project to add some major functionality to our SAP system for production planning.  Before we turn it on, we have to provide a big chunk of static historical data that it can use as the basis for future calculations.  (It's basically fake history so the system can function like it has been implemented forever as soon as it's turned on.)

 

The software folks have defined 9 data points with an average of 15 months of data each, all for about 800 materials.  The kick is that four of those nine are derivative of the other five.  Such as one row is monthly returns, and the row below it is an accumulated running total of those returns.

 

When I was taught programming and database design, we would never have made those calculated fields take up space in the database.  We would have calculated them whenever we needed them.  I mentioned this to the developer and she said that size doesn't matter and it would be slower that way, so she'd adamant about storing everything in its own table space.  These are data points that will be used once or twice a month, at most, and I thought a little slowdown was no big deal.  But I guess current best practice is to save everything.

 

I'm seeing more databases that are not relational with keys, but have every table hold all the data in itself, storing the same thing over and over and over.

 

These people would never have survived having to write a program that ran with a 64k ceiling. ;)



#2 the_stain

the_stain

    Phat O'Mic Chef Winner!

  • Patron
  • PipPipPipPipPipPip
  • 77500 posts

Posted 13 June 2019 - 06:25 AM

These people would never have survived having to write a program that ran with a 64k ceiling. ;)


Dude! Tell me about it. The product I support just keeps growing in functionality and along with that comes increasing resource demands. Our developers think nothing of adding some relatively minor functionality to the product that increases its RAM usage by 4gb. "Oh, memory is cheap these days". Christ,I remember when 4gb was all a server could hold!
  • 0

#3 davelew

davelew

    Comptroller of ACMSO That Are Not Beans

  • Members
  • PipPipPipPipPip
  • 13397 posts
  • LocationReading, Massachusetts

Posted 13 June 2019 - 08:06 AM

I see that with people running FEA on metal parts.  I was taught to use basic physics to figure out the forces and torques on each part, then use a computer to analyze the response of that part with complex geometry that couldn't be analyzed by hand.

 

Now people analyze large assemblies, set parts to "do not penetrate", and analyze everything including screw threads.  Less work for the person, more work for the computer.


  • 0

#4 TonyBrown

TonyBrown

    Comptroller of C-Blocking and Wet Streak Marks

  • Members
  • PipPipPipPipPipPip
  • 59744 posts
  • LocationAntioch, IL

Posted 13 June 2019 - 08:18 AM

sheer horsepower in machines these days has overcome a ton of sloppy and inefficient programming.

 

unfortunately.


  • 0

#5 ER Pemberton

ER Pemberton

    Comptroller of Forum Content

  • Moderators
  • PipPipPipPipPip
  • 33306 posts

Posted 13 June 2019 - 08:36 AM

sheer horsepower in machines these days has overcome a ton of sloppy and inefficient programming.

 

unfortunately.

Right.  Storage is cheap, memory is cheaper than it used to be and processor power is fast.  The only spot I run into issues is if I'm running something in a remote location and it's using the web to transfer things... I have to write as much stuff as I can to eliminate as many "round trips" as I can or I *WILL* see speed degradation.  



#6 Kellermeister

Kellermeister

    Comptroller of Grievances

  • Members
  • PipPipPipPip
  • 5208 posts
  • Locationthese are not the droids you are looking for

Posted 13 June 2019 - 01:09 PM

Linux
  • 0

#7 strangebrewer

strangebrewer

    Frequent Member

  • Moderators
  • PipPipPipPip
  • 1121 posts
  • LocationDenver, CO

Posted 13 June 2019 - 02:05 PM

sheer horsepower in machines these days has overcome a ton of sloppy and inefficient programming.

 

unfortunately.

 

So true and there will always be exceptions but the times are a changing.  I'm seeing more and more people dump vendors who's solutions require monster resources.  Not only are they tired of the footprint those solutions occupy but they are also finding they are hard to support with their existing staff, very hard to upgrade, and *reliable* new features take to long to come to market.  Fully managed on prem deployments are also on the outs.  SaaS, micro-services based architectures, and shared infrastructure designs (public cloud) are putting a hurting on the big ERP's of the world.  

 

I think SAP is still in a good place as they have options other than their behemoth on premises deployments but a lot of others names I don't hear used in the best context.



#8 Stout_fan

Stout_fan

    Frequent Member

  • Patron
  • PipPipPipPip
  • 1938 posts
  • LocationBalmer, Merlin, Hon

Posted 19 June 2019 - 08:49 AM

sheer horsepower in machines these days has overcome a ton of sloppy and inefficient programming.

 

unfortunately.

You sir, now understand what has made Micros**t Windows possible since its inception.


  • 0

#9 TonyBrown

TonyBrown

    Comptroller of C-Blocking and Wet Streak Marks

  • Members
  • PipPipPipPipPipPip
  • 59744 posts
  • LocationAntioch, IL

Posted 19 June 2019 - 08:51 AM

You sir, now understand what has made Micros**t Windows possible since its inception.

oh that's not some kind of revelation to me  :P


  • 0


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users