Choose an Appropriate Transaction Model
The single-transaction model tempts the inexperienced developer to ignore multiuser issues in favor of “easy programming.” The result is application architectures that perform poorly at all levels: slow queries and refresh responses, glutted networks, user-unfriendly workflows, and high levels of conflict.
Don’t Go “Generic” Unless You Need To
Generic application -to -database interfaces, such as ODBC or Borland’s BDE layers, merge a single database connection and a single transaction. Because their purpose is to hide the differences between low-end, file-based data repositories and sophisticated, transaction-capable database management systems, they do not support the capability to have multiple transactions concurrently active in a database session or to have a transaction that spans connections to multiple databases.
At best, these generic interfaces provide an easy route for scaling up low-end databases or flattening out the differences between different vendors’ DBMS implementations. If you don’t need the lowest common denominator, don’t choose it.
Exploit Multiple Transaction Capabilities
A Firebird client can run multiple concurrent transactions. A user working on multiple tasks in a single application can perform a variety of activities over the same (or over-lapping) sets of target data. Firebird’s transaction model provides great benefits for designs that need to cater for a modular, multiple -tasking environment in a highly responsive manner. It is an important responsibility for the software engineer to develop techniques to keep commits flowing and user views synchronized with data-base state.
Keep the OAT Moving!
A slow-moving OAT almost always indicates long-running transactions. Avoiding them is one of the best skills you can acquire when learning to write client applications for Firebird.
It is easy to blame long transactions on user behavior. You can help them to help themselves by teaching them to complete tasks within a reasonable time: not to go for coffee breaks, leaving tasks unfinished; not to submit “wild queries” at peak times; and so on. However, good client application design avoids depending on users to behave well.
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.