Week 22: CST 363 - Introduction to Database Systems

WK06: Database Programming – Bridging Code and Data

This week focused on how general-purpose programming languages talk to databases. I already work in .NET with C# and Dapper, so many patterns felt familiar - opening connections, parameterized commands, mapping rows to objects. It was nice to see the theory behind the practices I use daily. Java's JDBC sits in the same conceptual space as ADO.NET + Dapper: you load a driver, obtain a Connection, issue PreparedStatements for safe, reusable SQL, stream results via a ResultSet, and manage transactions. The idioms differ, but the building blocks rhyme.

ZyBooks Readings Recap

The readings framed database programming from first principles to practice. We started with language paradigms - imperative (procedural, object-oriented) vs. declarative - and why databases lean on declarative SQL: complex queries are easier to express and let the optimizer choose fast plans. But full applications need control flow, so you combine SQL with a host language, which creates syntax and paradigm gaps (blocks/loops vs. set-based results). To bridge those, we saw three techniques: Embedded SQL (e.g., EXEC SQL in C/COBOL) that's conceptually simple but dated - two-phase compilation, heavy round-trips, and wide gaps with OO languages; Procedural SQL (e.g., PL/SQL) that adds control flow, reduces network chatter, and enables whole-procedure optimization, but lacks the breadth of general languages; and APIs (ODBC/JDBC/ADO.NET/DB-API/PDO), now the dominant approach, which erase most syntax gap, compile in one step, and offer database independence via drivers and a driver manager. On capabilities, APIs converge: create connections, prepare queries for reuse, stream multi-row results via a cursor/reader, and call stored procedures. Architecturally, a driver talks to the database while a driver manager routes calls (and can layer other APIs). Finally, the JDBC/Connector-J specifics: obtain a Connection via DriverManager.getConnection, run SQL with Statement.executeQuery/executeUpdate/execute, iterate results with ResultSet.next() and typed getters, and prefer PreparedStatement with ? parameters both for performance (prepare/execute) and SQL-injection safety. Stored procedures use CallableStatement, with setXxx for IN params and registerOutParameter for OUT params.

Comments

Popular posts from this blog

Week 4. Class: CST 300 - Major Pro Seminar

Week 2. Class: CST 300 - Major Pro Seminar

Week 5. Class: CST 300 - Major Pro Seminar