JDBC vs JPA: Pros and Cons

[@azenkwed]

They love acronyms so much the A in JPA stands for API.

[@jaysizmir9432]

Love the way you explain things, thank you !

[@adamohm]

Very informative video, it helped me a lot. Good job and thank you!

[@shervin9561]

Thanks a lot for your great explanation

[@ShermukhammadKarimov]

great explanation, thanks much

[@maxfreund4803]

Love your explanations, man :)

[@davidtheprogrammer]

At 10:30 I assume he means "Spring Data JDBC" and not "Spring Data JPA" right?

[@ProCoderIO]

Yes! Good catch, because that was easy for it to slip past.

[@balajir6670]

Very good explanation, thank you

[@ProCoderIO]

What else needs to covered?

[@danhoward7697]

Persism is a often better option than those. Check it out.

[@ProCoderIO]

Took a peek. Interesting approach. Unfortunately it only has one committer and no changes for 8 months. As for “better than those”, Persism uses JDBC under the hood. Just check out github.com/sproket/Persism/blob/persism2/src/net/sf/persism/ConnectionType.java. Also, if I may add, kind of strange to bake in all your supported platforms instead of making it open ended.

[@adrianbornea]

Good explanation. Subscribed 👍🏻

[@ProCoderIO]

Thanks!

[@dowoyele]

Great video. Thank you. But should I learn JDBC or JPA. I feel like since JPA is more often used than JDBC, I should concentrate on JDBC. Please what do you think?

[@ProCoderIO]

I’d start with Spring Data JPA. Get your feet wet with JPA. It’s a very commonly used library. No harm learning. But it can also let you learn the shortcomings of JPA and what in turn; what Spring Data JDBC has to offer.

[@andrascsovari8607]

Great video, thanks for it also these lights make me feel uncomfortable, natural would work better for me

[@danielbristol6794]

In terms of performance like querying millions of records from database, which is faster?spring data jpa or jdbc?

[@ProCoderIO]

JPA is a bit tricky in these scenarios. JPA is simply a higher level query language translated into SQL by the JPA provider, so in the end, it becomes JDBC. The simplest queries would be probably be identical. Ensuring you have the right indexes and are running stats on the database are important. But when it comes time to "tune" your query based upon DBA feedback, it may be trickier to tune JPQL (or not). Again, depends on the scenario. This level of separation between written and actual query is what I feel made people VERY interested in Spring Data JDBC, and willing to trade in some of the JPA's feature set to get a little more control over the SQL.

[@shervin9561]

🔆

[@djhi-tek9249]

Why should i use java instead of nodejs?

[@ProCoderIO]

If you love Node.js, then use it! This video was simply about explaining what JDBC and JPA are, why some people see them as "different", the tradeoffs, and other aspects.

[@panchal6360]

Hey thanks for the explanation. Now i don't have to watch 3 different videos.

[@ProCoderIO]

Awesome! Is there something else you've been eager to see that would be handy as a video?

[@panchal6360]

Hmm, maybe some information about feignclients would be great. Btw thanks.

[@timw594]

I think this is a great video, but there are some old myths talked about here that frankly remain myths and many just wrong. #1. Companies are 4 to 5x more likely to change the programmatic front-end UI and app stack then they are the actual backend RDBMS. #2. far more rare is to decide to change the RDBMS alone.... almost 95% of the time when they are changing the RDBMS they are also changing the entire tech stack (aka company acquistion, merger etc...) #3. There is more standard cross functionality in the main RDBMS platforms than any front-end UI app stack created to date. If you look at PL/SQL and SQL across the big vendors DB2, Oracle , MySQL, SQL Server vs Postgres. The truth is about 95% of what you need and use most frequently is about 95% the same across all of the vendors. There use to be allot more differences in the 90's and early 2000's but the good thing about RDBMS and the SQL ansi standard is that almost all of these vendors end up landing in the same area when it comes to standards and evolved in the same ways. #4. Trying to pretend like any of these stacks are going to keep you out of the late night calls on "Forgot to close a cursor"... or a transaction log filled up... or someone did a cartesian product is 100% untrue when on any project of complexity. This is why you either make sure someone on your team has expertise in backend app development or in many situations a DBA can pull double duty to keep this from happening. Matter of fact having good backend knowledge on the team to start with will keep you out of ALL of these problems and make the stack much much simpler. #5. SQL and PL/SQL are INCREDIBLY easy and they haven't changed much in 30+ years... and they handle things more efficiently inside the RDBMS than any outside language can. And on almost every project and simple and complex CRUD operations can be centrally controlled in one location for tuning, adding additional outside of core app functionality etc. #6. Many times these days a business database will have more than one interface and centrally locating/abstracting CRUD operations in the database centrally control the logic/behavior and eliminate multiple front-end access points from having variation in they way they say... Create a new customer... create a new contract etc...

[@ProCoderIO]

Glad you liked the video. And you have some very valid points (thanks for writing them in such detail). I'll try to respond to each one below: #1 - Agreed. Changing the backend is VERY rare. #2 - Agreed. I was trying to speak to the point where you get sold this bill of goods about "JPA protects you from the underlying DB." Companies don't REALLY change that much. But developers seem prone to lap this one up, as if writing JPA is somehow "easier" than writing for the platform that you're on. #3 - This is indeed true. Most of the "core" SQL stuff we use today works pretty well on all of them. It's just little stuff like "string concatenation" I've stumbled across is NOT portable. Also, some of the newer features like JSON operators tends to be platform-specific and NOT found across all the platforms. And yes, the era I wrote gobs of SQL was early 2000s, so when I'd spend weeks working on Oracle and then attempt to fashion a query for some business analyst in MS Access, I'd get burned on little stuff. #4 - I got called in plenty of times for the database being maxed out. Sometimes during the day. But often it would happen at night. Once, I was called in 3x on the same night, albeit not for being out of cursors. But the "forgot to close your cursors" thing was real for not just me but others on our team. And it would hit us again. Probably because we would implement three queries at once and "forget" to properly close all three. Murphy's Law?? Anyway, one would be the breaking point. We'd fix it. And it would take 6-12 weeks for the NEXT one to reach some breaking point. Rinse/repeat. This was a mixture of good ole J2EE back in the day for one app, and a non-Java app for another, we'd see the problem on both. Tools like Spring's JdbcTemplate, were it adopted, would eliminate a whole class of errors from ever happening. Pretty good bargain in my book. #5 - Yes, stored procedures and views and other things that move stuff INSIDE the DB typically are more performance. But you tend to migrate toward a different development style. We frankly would have required more time contribution from our DBA team to do that. And we had a limited budget. App developers writing SQL queries in their applications was an agreeable approach compared to stuffing everything into stored procedures and then tapping the DBA team when the stored procedure had to be patched/updated. At that point, you aren't really DOING data persistence in your application. You're just invoking remote APIs through the database driver. And this can be done with either JPA or JDBC. The differences between the two kind of dwindle in that context. As for how "easy" that approach is well...I watched someone that was supposedly better at SQL/PLSQL than me build a query by joining multiple views together to get the results he needed. Guy didn't realize he was joining the same table 20 times, thus causing the query to take 20 minutes to run. When he rolled off the contract and I picked up his app, it took me three weeks to grok it and then rewrite it. Query went sub-second and the department using it gave me a cute certificate award. Not everyone comprehends relational databases. Part of my point of this video is that developers, for years, were pitched that JPA/Hibernate makes it where you don't HAVE to understand the database. And that is simply wrong. #6 - That is a VERY valid point. If the database is simply the raw data and each app is gluing it together differently, you run the risk of not upholding the contract. We had the fortune of having one person from the DBA team assigned to the developers team so that we could ensure that ALL of us were doing the "same thing" with regarding to the data. The fact that we couldn't practically adopt stored procedures nor were we all even using the same technology (Java vs. Non-Java apps) meant we REALLY had to ensure our queries & views were properly aligned. And this guy helped us do just that. I'm hoping to not purport myths but instead address some of the assumptions people make with what JPA is and what JDBC is. And that by digging a little deeper, and understanding a little more, people can better use both of these technologies to achieve their solutions. Thanks for stopping by. Hope you'll tune in for more of my videos!

[@timw594]

@@ProCoderIO very good stuff here seriously. Thanks for the detailed response. Im a full stack developer but a deep data engineer and architect w heavy RDBMS background... I guess I personally at these persistence layers at being allot more complex vs leveraging the RDBMS directly. As to where others might feel it's easier the other way.