Databases Reference
In-Depth Information
Sizing
The size of databases is constantly increasing. These days e-business
databases will routinely begin to approach the terabyte range and enter
into the realm of what are commonly called “Very Large Databases”. This
poses two challenges. The first is to be able to estimate the rate of growth
and ensure that appropriate processes to manage this volume of data are
put in place. This may involve regular archiving of information into a
backup data warehouse while keeping the “live” database within manage-
able limits. The second challenge is to determine and obtain the appropri-
ate hardware for the size of the database expected. Significant investments
in hardware to help improve performance must not be ruled out and all lim-
its from a hardware perspective, such as increasing the RAM or number of
processors, must be explored.
Data Organization
The organization of the data within the database is the most important
factor influencing the performance of the database. This involves building
a list of data requirements, translating the same into a data model, normal-
izing the data model and implementing the normalized structure in the
database. However it must be cautioned that non-normalized databases
are found in commercial applications and this may actually enhance per-
formance as per the application requirements. Another key factor that may
need to be considered is the skew in the data that one expects to store. In
a relational database, data is “skewed” when the distinct values in a column
are not uniformly distributed over the table's rows. Expected instances of
skew in data must be duly considered while designing SQL queries and cre-
ating indexes.
Database Design
Finally the traditional issues that must be considered during database
design must not be ignored. These include but are not limited to the following:
•
Simplicity.
An attempt must be made to keep the queries focused and
simple. Many tasks may be better accomplished at the client end rath-
er than at the server side.
•
Get rid of useless indexes.
While having appropriate indexes has al-
ways been emphasized, lately more emphasis has been placed on re-
moving (or concatenating the other way round) indexes which may
not be used.
•
Pay attention to nested scans.
On an enormous table, indexes are rare-
ly lightweight themselves, even if they seem small by comparison. A
full index scan, and even a range scan can significant performance
implications.
Search WWH ::
Custom Search