And here we are. The last day of Oracle OpenWorld 2016…
The first session I went to was a panel session called “Thinking Clearly About Database Application Architecture” with Gerald Venzl, Bryn Llewellyn, Connor McDonald, Toon Koppelaars, Cary Millsap. The session started with an introduction by Toon, explaining how the thick database architecture model is provably superior to the thin database model, especially from a performance perspective. I am definintely in this camp, so they were preaching to the converted, but IMHO some of the most interesting comments came from Gerald. To paraphrase, and I hope I didn’t distort his meaning…
- The object model favoured by most developers (Java, C#, Javascript etc.) does not fit well with the set-based approach of relational databases, which is why they rely so heavily on persistence layers to bridge the gap. The challenge is how to make them coexist.
- Oracle is not the only database technology being used out there. Depending on the engine, the thick database approach may be more difficult or even impossible. That may make developers less likely to adopt it.
I liked both of these comments for a variety of reasons.
- We need to make what we do more accessible to the current crop of developers by putting it in a form they find acceptable. Making the PL/SQL APIs we produce available to non-PL/SQL developers through REST web services (see ORDS) might be one way we could do this.
- Thick or thin doesn’t have to be a binary decision. You might choose a middle ground (chubby?). For example, you can have a transactional layer (not table APIs) with some logic in the database, that allows you to leverage the power of the engine. Oracle, SQL Server and MySQL are all capable of doing this. You can use this transactional layer as the foundation of your business logic layer, which may be in the database, if that is your choice, or in the application server depending on your needs. I have a preference, but making it a binary decision marginalises people. Some may say this halfway house is not the best solution, but I would argue a halfway is better than nothing, as well as sowing seeds for the future…
I spent the gap between this session and the next one speaking to John Clarke from the Real-World Performance Group. Clever guy!
Next up was a panel session called “Optimizing SQL for Performance and Maintainability” with me, Keith Laker, Nigel Bayliss, Chris Saxon, John Clarke and Connor McDonald. The most scary thing about being on a panel is actually trying to understand the questions. From the stage the PA echoed so much I could barely understand a word. 🙂 We got through quite a few questions and had a lot of laughs. I think it went well. 🙂
From there it was back to the hotel. I ended up standing outside chatting to a bunch of people for ages, then it was some goodbyes and back to my room. I’ve got an early start tomorrow for the trip home, so it was going to be an early night…
After a while I got a DM from Debra asking me to collect an oraclenerd towel and I was persuaded to go out to eat pizza. So not so much of an early night.
Let’s see how tomorrow goes… 🙂
Cheers
Tim…
Hi Tim,
Thanks for your remarks about the DB application architecture panel, possibly the session that most interests me from afar. It’s a big and important subject.
I very much agree with Gerald’s and your comments. The “thick database” model is great, but it does not provide a complete data access solution. For that, the application needs a proper data access layer that translates between the application object model and the database API. Just providing drivers (or REST interfaces) is not enough. So we need solutions that are specific to each language, and that look at the database from the outside, not the inside.
So it was just talk? Oracle is doing nothing to address this issue?
The remark about other databases not being “thick enough” chilled my blood. I hate the idea of dumbing down the DB side of things to the least common denominator. If we do that, why keep the most expensive database?
Anyway, thanks for sharing!
Stew: No answers on that front. Just talk. 🙂
My comments weren’t meant to suggest a general lowest common denominator approach in its entirety. My point is that for some shops that will be the appropriate level to take. For some, especially those that focus on Oracle, they have more options. For those in mixed environments, multiple relational and non-relations engines, there requirements are different, which makes PL/SQL potentially a less strategic option for them. There is no right and wrong answer. It always depends…
Cheers
Tim…