_____ INC

Best Practices in
Database
Development
For the _____ IS/IT Department
_____
8/17/2009

This document is a ‘white paper,’ aimed at persons with some database

development, application development, and/or database administration experience.
It is intended to provide an overview of potential problems and solutions when
developing applications where the data is stored in databases. In particular, issues
surrounding data longevity, data modeling, applications development, security, and
scalability are addressed. The guidelines outlined in the summary, in particular,
should be addressed in the design of all new development and upgrades of
database systems and applications.
 2

1 Best Practice in Database Development

1.1 Introduction
This guide is an application and database design ‘White Paper,’ and is directed at
persons with some experience in Application Development, Database Development,
and/or Database Administration. It is intended to provide a comprehensive review
of the potential problems (and their solutions) when developing applications and
their underlying databases.

1.2 Successful database applications

• An Application built around (and dependant) on the database, will succeed or fail,
based on how it uses the database.

• Applications come, applications go. The data, however, lives essentially forever.
In the long term, the goal is not about building applications, it is really about using
(and protecting) the data that is underneath, or behind these applications.

• A development team needs at its heart, one or more developers, knowledgeable

in database development, who are responsible for ensuring the database logic is
sound and the system is built to perform from day one. Design ‘Tuning’ after the
fact (tuning after development) typically means that the developer did not give
serious thought to these concerns during the development process.

1.3 Database design – Indexes, Referential Integrity

and Statistics
1.3.1 Enforce your business model at the database level
Your business model should be implemented and enforced at the database level.
Let me repeat this - Your business model should be implemented and enforced at
the database level. The initial application analysis will identify the logical data
objects and their relationship to each other, even before you choose your database
platform or create a single line of application code. Not every application will
require a data model in Third Normal Form, however when designing your physical
data model from your logical data model, the logical relationships should be
enforced in the physical model using referential integrity constraints. In other
words, using Primary keys and Foreign keys. Even when an application may not
require data in the third normal form, the database should be designed in third
normal form, and only de-normalized when necessary for performance.

1.3.1.1 Business logic

Business rules = Data rules. For example, “you can only be an employee if you are
in a department” should be instantiated as a mandatory foreign key on an
 2

employee table to the primary key on a department table. Not only does this
enforce the integrity of your data, it will have an add-on effect to the performance
of your queries by giving the database optimizer the correct information to
determine the most effective query paths. Likewise, “A Purchase Order detail MUST
reference a valid Purchase Order,” should be instantiated as a mandatory foreign
key on the Purchase Order Detail table to the primary key on the Purchase Order
table.

1.3.1.2 Application logic

Application specific logic is not enforced in the database.

1.3.2 Indexing and index types

Indexes enable faster searching and (depending on design) faster updates. Be
aware that differing database structures will require differing index strategies, and
these decisions should be made in the initial design phase.

You will also need to be aware of the differing types of index that are available to
you, and when it would be appropriate (and just as importantly, when it would not
be appropriate) to use them.

1.3.3 Statistics and their place in query optimization

Indexes, primary and foreign keys, domain and unique constraints do more than
enforce the relationship of data objects to each other. The database kernel needs
information to optimize execution paths of your queries, procedures, functions and
packages, as well as efficiently allocate database and system resources. Usually,
this information is in the form of database statistics, held within the databases’ data
dictionary. Statistics may have to be manually gathered, or you may be able to
generate them automatically. Your DBA will advise you here, however it is
important to understand that unless your database has up-to date and complete
statistics for each object in your database, the optimizer will be unable to calculate
the most effective execution plan for your application queries.

1.3.4 Explain plans and benchmarking

Explain plans or Execution plans are reports on how your query is executed. They
will contain information regarding what indexes were used, what tables were
scanned, how many blocks and rows were accessed to return your result sets, and
an indication of what effort your query costs the database server, in terms of CPU
seconds, IO operations and waits. They are a very effective tool to tune your
applications, so take the time to learn how to generate and read explain plans on
your database platform.

1.4 Writing SQL Statements

 2

At its most basic level, interaction with a database is easy. To retrieve information,
READ or SELECT. To create, CREATE or INSERT. To change, UPDATE, and to remove,
DELETE. Point these statements at database tables or views; use generic code
generators, application development tools and the data manipulation procedures
are done. If we’re not sure what tables we want to access, or what fields we want
until we get some input from the end user, it’s very simple to build the query into a
string and then execute the string through a JDBC (or equivalent) call.
Unfortunately, that design approach is fundamentally flawed on a number of levels,
the most important areas being security, scalability and performance.

For every database application the mechanics of executing a query need to be

understood, even if you are using a generic code generator - because the SQL code
that is generated from these tools will probably not be optimized, at best, and can
potentially be dangerously inefficient at worst. You need to be able to SEE the
generated code and then decide if it’s appropriate. Code generators should not be
used as a screen used to hide SQL ignorance. Bad SQL is just that, regardless of
who (or what) generates it, and it’s up to you to ensure that every piece of code you
write or are responsible for is fit for purpose, and that goes way beyond just the
immediate INSERT, SELECT, UPDATE or DELETE operation you want to perform.

1.5 Bind Variables for efficiency and security

1.5.1 Query parsing, binding and execution - Overview
In the database server, after syntax checking, the query is parsed into memory and
the database checks to see if the query already exists in memory. If it doesn’t, it
has to be security checked, optimized, an execution plan for the query has to be
generated in server memory, then the query parameters are bound and the query is
executed. This is a significant task, and it’s a lot of work; it consumes a lot of
resources - and more importantly, can lock objects to prevent database corruption
while this work is being done, preventing other session from accessing these
objects. Database instance memory and resources are finite, and we do not want to
find ourselves in a situation when we run out of memory or we are locking resources
because of badly designed SQL. Be aware that it can take only one badly written
SQL statement to cause a problem to falter (or, other applications to falter) –
regardless of the fact that all other queries are 100% optimized and well written.

As an application developer, you do not want to find yourself in a situation that

every query you issue from your application has to be hard parsed. Parsing is an
expensive operation for the database and can be a performance and scalability
killer. What you want to see is your application using the existing execution paths
and query plans already in the database memory as much as possible, i.e. soft
parsing. So you need to design your SQL code to be as universal as possible, and
that means binding your variables to your SQL Statements at execution time,
regardless of where the query originates from. The way this is done will vary from
 2

database to database, and application to application, but the one constant across
the varying technology is that refusing to use bind variables will potentially not only
open your application up to quite severe security risks, it will also be a prime cause
of your application not being able to scale up, or perform under load.

Application developers and Project Managers should make sure that the technology
being used to interact with any RDBMS system supports the ability to issue queries
with bind variables. Unbound queries can destroy the ability of your application to
scale and run efficiently. And even though this should be obvious, it bears
repeating - string substitution in an SQL query is not binding variables.
 2

1.5.2 Bind variable example

For example, to retrieve the details of employee # 123 from the employee table,
you could
Select * from emp where empno = 123;

Alternatively, you could

Select * from emp where empno = :empno
With a variation of “using (123)” to bind the variable.

The first query will have to be hard parsed every time you issue the query with a
different employee number – and if this query is going to be executed many times
with different parameters, you will flood your database’s memory area with multiple
copies of the same statement. Once this occurs, then every new query will have to
be hard parsed, as well as possibly (depending on the database platform) the
unwelcome side affect of causing your database to start page swapping into your
virtual memory with all the unwelcome IO operations that entails.

However, the second query will only have to be checked, optimized and parsed
once, and once only, (at worst,) for each active connection.

1.5.3 Bind Variables prevent SQL Injection

For example, assume you have a procedure with two parameters you wish to call
from your database application. You set up the statement like this:

Stmt = “begin p(‘” & input1 & “’, ‘” & input2 & “’ ); end;”

Your user types in

Input1 = x’. ‘y’); execute immediate ‘drop table all_salaries’; end;
--
Input2 =

Your application then runs stmt on your database, which is this:

Begin p(‘x’, ‘y’ ); execute immediate ‘drop table all_salaries’; end;

--

Now you have to explain to your line manager, director and reporting partner why
the salary table has been dropped, and unless you have auditing functions turned
on, this will be very hard to trace.

As an exercise, I suggest you Google “sql injection”. The importance of bind

variables in avoiding this situation cannot be overstated.
 2

Programmatic constructs like this:

Stmt = “begin p(‘” & input1 & “’, ‘” & input2 & “’ ); end;”

and their variations are not binding variables. Use your technologies variation of
the Java

PreparedStatement.
PreparedStatement pstat =
Conn.prepareStatement
(“begin p(?, ?); end;”);
Pstat.setString(1, );
Pstat.setString(2, );

Bind variables are not just about performance; they are also about security. This is
particularly important if you are using a code generator, or dealing with third party
software.

1.6 Query hints

Some database platforms support the use of “hints”. Hints are directives to the
optimizer to change the execution plan of the query.

Unless you are intimately acquainted with the underlying architecture of your
database platform’s optimizer, and you have extensively benchmarked your
changes, and you have discrete, quantifiable and definite performance reasons to
use hints, and you fully understand the internal mechanics of what the hint will do
to your execution paths under load, leave them alone. Under almost all
circumstances, the database optimizer will have come up with the optimal query
execution plan for your given query.
This of course presumes that your database design and indexing strategy is valid.
Remember - a hint is not a quick fix for poor database design.

1.7 Transaction Design

Transactional design will have implications on how your application will scale and
perform. Issues and design questions you will have to answer include:

• How do we prevent “lost updates”?

• How do we guarantee transactional integrity, and the underlying integrity of
our data?
• How do we guarantee a consistent view of data to the end users of our
applications?
• What locking model and isolation levels are available in the particular database
 2

we are using – and they are different between different databases – and how will
this affect our design?
• How to design appropriate methods and rules to cater for this?
The most efficient way is to package your transactions into stored procedures in
SQL Server and packages in Oracle, and use static SQL as much as possible.
Certainly within an Oracle instance, the first time a package is called in your
session, it is pinned into the shared pool, and the static SQL statements are
parsed and the explain plans written, so when the packages are called again,
they just execute – no need for a hard or soft parse. This is one of the most
pressing arguments for the usage of properly designed stored procedures and
static SQL – “parse once, execute many”. A good philosophy to adopt when
designing database applications and the associated SQL transactions is -
• Do it in one SQL statement if you possibly can; think in terms of set processing,
not row-by-row - especially for bulk processes.
• If you can’t do it in one SQL statement, then a little database native procedural
code (ie. PL/SQL on Oracle, or T-SQL in SQL Server) wrapped around well
designed SQL statements will almost certainly solve most problems – but
remember to think in terms of processing “sets” of data. Keep your procedural
programs small and explicit, and designed to solve one specific problem.
• If for whatever reason, native procedural code (and this includes native Java
libraries in both Oracle and SQL Server) won’t give you what you need – and this
should RARELY be necessary – then an external call to a Java library or C/C+
+/C#/Assembler dll could be justified.
• If that won’t do it, you probably shouldn’t be trying it in the first place, or your
design is fundamentally flawed
• AVOID dynamic SQL unless you have absolutely no other choice; dynamic SQL
is very easy to code, but it can be complicated to code properly and if you don’t
code it properly, you run the risk of flooding the instance memory area with
queries that have to be hard parsed every time and that can bring a database to
its knees.

Further, using database packages and procedures, you can make use of the
appropriate methods to lock you records for INSERTS and UPDATES depending on
your database, and elegantly handle any waits or exceptions you may encounter.

AUTOCOMMIT should always be turned off to preserve transactional integrity. Let’s

say you have a process that updates records in five tables, and because of the
design of the data, you need to perform this process in three separate SQL
Statements. The first statement executes without error, as does the second. The
third fails for some reason (maybe it violates a unique constraint) – so the entire
transaction should be rolled back, but if the separate prior statements have been
AUTOCOMMITed, you have a problem. As an application designer, it is up to you to
decide the success or failure of a transaction and when to explicitly commit or
 2

rollback. Do NOT assume that the database server’s auto-commit knows your
database design, because, it is a virtual certainty that it does not.

1.8 Database locking

Pragmatically, you also need to have a very good idea of the data usage your
application will need, so you can decide what approach to take - what’s not so
important in a reporting database with few users becomes critical in a large OLTP
system with a high number of concurrent users. Likewise, a few wasted bytes in
tables with a few million rows and few indexes will have little impact on your
application, but, let the table and associated indexes approach gigabytes in size,
and your application could be brought to its knees. But, regardless of whether
record locking will be an issue for your application or not, you must know how a
particular database locks, what the implications are and how best to design your
transactions. This is not really something that can be done generically (and it really
shouldn’t be handled at the application level, either) – every database is different in
the way it handles locks and latches, indexing and memory allocation, and no one
approach will work effectively across all database platforms.

1.9 Database native SQL extensions

PostgreSQL, SQLServer and Oracle all have a rich set of SQL extensions that go far
beyond ANSI standard SQL, and as a good developer you should know what they
are and how to use them, because, if you do, it will make you job much, much
easier. You should also have a good working knowledge of how your queries will be
parsed, and the mechanisms your database will use to optimize your queries, so
you can write and tune efficient SQL. Remember, you should be designing your
applications for scalability and performance, from the very beginning of your project
lifecycle. If you do not, you will very likely be spending a great deal more time
later, fixing your database or not (and making subsequent application changes)
under less than ideal conditions.

1.10 Dynamic SQL

In spite of the fact that well designed dynamic SQL can be as efficient as static SQL
if it is written properly, it is very easy to write very bad dynamic SQL. The
implementations of dynamic SQL will vary widely across database platforms, so if
you have to use dynamic SQL, make sure you know what’s available, how and why
it works as it does, and what the implications are - because one method may be
appropriate for one set of circumstances, another method may be appropriate for
another.

For example, in Oracle databases, version 8.1.6 and above, there are two methods
for generating dynamic SQL - Native Dynamic SQL and the DBMS_SQL API package
which was introduced in version 7.1. The differences between these two methods
are quite pronounced, even though they both provide a similar service, so it would
 2

be important to choose the correct method depending on which type of transaction

you want to perform.

1.11 Dynamic SQL guidelines with Java and .Net

If you absolutely MUST generate a dynamic SQL statement from within your Java
classes or .Net applications ALWAYS use a method that allows you to bind variables
(ie. for Java, use PreparedStatement, and not Statement. PreparedStatement
supports the use of binds. Statement does not. Refer back to section 1.4.2).

A better approach would be to make a call to a properly designed database

package/stored procedure or function that will build the (optimized) dynamic
statement for you, and return a resultset or value set that you can then manipulate
as you see fit.

Make sure your web services/Java Beans/ORBs/J2EE/.Net/COM apps are binding; this
is particularly important with 3rd party software you didn’t develop, or when using a
design tool that generates the SQL for you. At the very least, you must have the
ability to examine the actual SQL that has been generated. Once again, if the tools
you have been provided with do not support binding, or the ability to call a
database package, flag this as a risk to your Project Manager.

1.12 Achieving true Database independence.

Enterprise standard databases exist for one purpose and one purpose only. To
store, validate, secure and manipulate data in the most efficient way possible. No
matter how sophisticated a middle layer technology is, it WILL NOT match the
native performance and scalability of the underlying database to securely and
consistently process data related transactions – so long as the underlying processes
have been properly designed. Anybody who says differently is trying to sell you
something. After the thousands of man-years and billions of dollars of R&D that
IBM, Microsoft, SAP and Oracle have put into their database products, no third party
middle tier layer can match the performance, security, ability to scale, and ability to
manipulate data of any of these Enterprise standard RDBMS systems.

The trade off for this brilliant functionality and performance, is that you, the
developer, and your development team, have the responsibility to know and
understand what tools are available to you across all aspects of your project, but
particularly so within your database. Have a serious review, in the design and
architecture phase, about what you want your application database to do, and how
best to interact with it. It is the IT Department Manager’s responsibility to ensure
that the team has a Database Administrator available, to assist with the choices of
technology available from the database.

Your database structures should be implemented from properly designed data

 2

models, with the appropriate referential integrity, primary and unique key
constraints and the proper index strategies in place. It’s important to remember
this – applications and technology come and go. C# / .Net / J2EE / CORBA / RMI /
WebServices / Applet / Servlet / Client-Server applications may not be around in five
years, as new technologies emerge. Your data, however, has a much longer
lifecycle and is far more valuable. Your database may be only supporting one
application initially, but data is an extremely valuable asset; other applications may
want to utilize your data and the variety of platforms and technologies vary
enormously.

Instead of building and executing SELECT, UPDATE, DELETE or INSERT statements in

your application – perhaps even “invisible” statements generated by a generic code
generator - you should be making calls to publicly visible transactional components
on the database – like:

• FIRE_EMPLOYEE,
• HIRE_EMPLOYEE,
• GET_EMPLOYEE_DETAILS,
• GIVE_ME_A_PROMOTION.

These can be package, procedure or function calls, calls to updateable views or

TABLE calls to pipelined functions. What you should be trying to achieve are
transaction APIs. Note – this does not mean Table APIs.

The advantage of this approach is that your transactions can be re-used by almost
any other application, and you have a much more consistent ability to secure
access to your data. Your DML statements have been optimized for your data
structures and RDBMS product and version, you know that the queries have been
optimized against your particular schema (and be aware that query design and
optimization will probably change during your load testing phase), if appropriate the
correct record locking design has been incorporated and you know your application
will scale securely.

This approach also simplifies maintenance. If you have a package/stored procedure

API where you discover a bug in the SQL, it is very easy to extract the SQL, apply
the bug fix and tune the SQL, zap the stored procedure and the change is
immediately and automatically propagated to every application system that uses
the updated stored procedure.

If however, the SQL is propagated in a number of Java classes or .Net objects, the
problem is exacerbated by the necessity of having to locate each instance of the
object and apply the fix.
In fact, you should give very serious thought to not allowing your applications
access to the underlying tables at all – the application interacts with the data only
 2

through carefully designed packages, procedures, views and functions, and these
database objects are the only objects the application can see or use.

1.13 In Summary

1. Data manipulation should be done in the database, so that

a. You encapsulate your logic in a stored procedure or package.

b. You do so in a single SQL statement if at all possible.
c. If you can’t, use as little procedural code as possible.
d. If that doesn’t work, (unlikely in about 99% of cases), use an external
procedure call. But, unless your application is cutting (or bleeding) edge, this
is potentially an alarm bell, that either your design is flawed, or, that you’re
attempting to do something you really should not.

2. Test and benchmark EVERYTHING; there’s almost always a better and/or

simpler way of doing something – actively seek it out and make your code
smaller, tighter and faster.

3. Be aware of the new features on new database releases, these can make
your life much easier.

4. Business logic should be enforced in the database. Period. Application logic

should be enforced in the application.

5. Code generators can be problematic, as generic SQL statements generated

will rarely be optimized for the database platform with which you are developing.
If your code generator doesn’t support binding variables, and you don’t have the
ability to see and tune what SQL the code generator is creating, then you should
give very serious thought to replacing it. Unbound code presents a severe
security risk because of SQL Injection, and your Project Manager should be made
aware of this. If you don’t, and your application doesn’t perform on deployment
to production, you’ll be running the risk of the production DBAs telling you
there’s nothing wrong with the database instance and configuration, and there is
nothing they can do to help you.

6. When you’re manipulating data, think in sets, particularly during data loads.
Row-by-row processing is usually inefficient and unnecessary, except in OLAP
transaction systems, and even then set based updates should be applied if
possible. Looping selects and updates over a network can result in severe
performance degradation. Do it all in a single statement if you can.

7. NEVER, EVER issue a COMMIT in a FOR loop. There may be circumstances

 2

when you do need to use a FOR loop and bulk processing on an update, insertion
or deletion, but COMMITs in any kind of FOR loop are dangerous because they
break your transactional integrity. COMMITs in for loops can also be very
inefficient and generate a considerable amount more redo than single
transactions. One senior DBA puts it very succinctly: “Using any form of auto-
commit is one of the safest routes to an un-scalable and error-prone application.
First of all, you shouldn’t split up a logical transaction into many physical
transactions. If any of these physical transactions fail, in what hybrid state is
your database? How do you restart the process?... There are many ways to stay
out of hell. Doing things properly is one. Not committing inside a loop is
another. Start doing things properly and stop hacking”

8. XML – if there are alternatives to processing XML, try these methods first.
Large XML documents or volumes are memory inefficient, processor intensive,
and can therefore be very slow to process. Smaller documents shouldn’t prove
problematic, though, unless the transaction volumes are high. Remember, XML
was designed for, and is most effective as a means of packaging data sets with
metadata, for transparently copying the data from one system to another – not
as a database data super-type.

9. Design your resultsets to return just the information you want over the
network. It’s a waste of resources to SELECT * FROM [table] when all you want is
one or two fields from a few records.

10. Dynamic SQL can be a trap. Either learn to do it very, very well, or leave it
well alone.

11. As a general rule, BIND EVERY VARIABLE. Yes, there are exceptions, but
your database specific DBA will advise you of these, and when they are
appropriate.

12. Know your database - How the data is related, what business rules are
enforced, etc.

13. Know your database server – what features it has, how it locks, how it
handles transactions, and how indexes are handled. Each database server will
be different.

14. Try, as far as possible, to encapsulate all known transactions within your
application into database stored procedures. By creating a set of database
transaction API’s, you will simplify access to your system, as well as enhance
performance, scalability and security.
 2

15. Normalize your tables to third normal form; only de-normalize when
necessary for performance, and with full knowledge of the implications, risks,
and rewards of the de-normalization that you are considering. Remember, in the
long run, well-normalized tables are easier to maintain, update, and use for most
purposes, than are de-normalized tables, and un-normalized tables can lead to
many difficult situations and data anomalies.

16. Talk to Technical Data Architects and other experienced developers in other
disciplines; their experiences may be able to help you solve problems in your
own discipline. If they give you advice, seriously entertain the thought of
implementing their feedback, even though it might run counter to what you’ve
been led to believe, or to how you’ve written applications in the past. Above
all, do NOT operate in a vacuum, isolated from the other disciplines, as this is an
almost certain approach to failure in some manner, for the application as a
whole.