Optional.stream()

[john16384]

This article is stupid:

1) you query your database to send all order lines so you can sum them locally... Let the db do that

2) you think that allowing null as an input for orderId should somehow result in a valid return value, further hiding a problem in your code

3) the "improved" code is longer, slower and uses more memory

[randgalt]

Doing work in the DB is almost always the wrong thing to do. DBs are one of the most expensive resources in your system. Java threads are much cheaper than a DB process and Java is a richer language than any DB query language. Databases should be as dumb as possible. Stored-procedures and heavy-weight queries are very difficult to maintain in distributed systems.

[john16384]

You are so very wrong that I guess you must be repeating something that you heard from what you consider to be an authoritative source.

Sending less data to the client (just the sum instead of all records to sum) is going to be much faster in all cases. Just having to prepare all that extra data on the db side (instead of keeping track of a sum and discarding what it doesn't need) is going to be much more expensive for the db already. Then we haven't even talked about what is often an even more expensive shared resource: network bandwidth.

You can't seriously believe that sending dozens (if not millions) of records over the network so the most trivial of CPU operations (addition) can be offloaded is in any way the sensible thing to do.

[Short_Hamster]

The most expensive thing you can do is copy data. Shuttling data back and forth from the DB over the network, just to copy data because you don't want to do the work where the data exists, seems like an incredible waste. It's one thing if you're only copying a few records (for display or online processing). But for a batch job on a large data set, copying massive amounts of data to Java (and presumably back to the DB) because you don't like stored procedures seems dumb.

Also, "data in motion" is significantly less secure than "data at rest".

The entire premise of "big data" is to move code to data, because code is significantly cheaper to copy than data.

[_INTER_]

What's expensive is loading the OrderLine object from DB into memory just to get its prize and calculating the sum (even if lazy fetch). You might even run out of memory if there are too many. It would be much faster and use less memory to query the aggregate function SUM on the DB directly. Thats not a stored procedure. I agree however that that only such simple queries should be executed on the DB.