- Achieving Optimal Databas Applikcation Perfomance and Scalability
- 2009. Pearson Education Inc
Viele Aussagen, häufig etwas simpel
Database Middleware
- Type 1 JDBC Drivers: Bridge
- Application ==> JDBC API ==> JDBC Driver manager ==> JDBC-ODBC Bridge
- ODBC Driver ==> database API (= db wire protocol) ==>
- Database
- häufig schlechter Performance, Funktionalität, Security
- Type 2 JDBC Drivers: Database Client-Based = Native-API Driver specification
- Application ==> Database Driver ==> Client Based Protocol
- Client Software ==> Dababase API
- Database
- mühsame Installation der DatabaseAbhängigen Client Software auf jedem Client
- Type 4: Database Wire Protocol Architecture
- Application ==> StandardsBasedCalls
- Database Driver ==> Database Wire Protocol
- Database
- allgemein empfohlen
für bulk loading Operationen gibt es ein Standars based API (statt Utilities)
ODBC Applications: writing good code
- Connections herstellen ist teuer
- Connections: Poooling falls geeignet, selbe Connection für mehrer Statements usw.
- Transactions: set auotcommit off, distibuted teurer als local usw.
- Prepare reuse, Parameter Markers, auch für stored Procedures
- Arrays für multiRow fetch/insert/update
- ODBC Cursor Library simuliert scrollable Cursors für DBSysteme die das nicht können ==> nur DB das nicht native kann und wirklich nötig
- fetch (long) data erst wenn wirklich benötigt
- SQLBindCold statt SQLGetData, SqlExtendedFetch statt SQLFetch usw.
- Catalog Funktionen sind teuer- besser describe auf (dummy) query
JDBC Applications: writing good code
meistes wie für ODBC, zusätzlich
- executeBatch entspricht MultiInsert etc.
- getInt etc. ist natürlich effizienter als getObject (für primitive type), column number ist effizienter als name ...
.NET Applications: Writing Good Code
analog