The techniques you will learn in this module are powerful, but there is no magic formula you can follow to maximize database performance. There are a number of reasons for this:

1. Every database is different. Your choices regarding which tables to combine often depend entirely on the tables themselves and your organization's needs.
2. Your organization's needs may change over time, requiring you to change your database's physical design.

Every RDBMS handles joins and searches differently. Because the best physical design for a database under one RDBMS is not necessarily the best physical design for that database under another RDBMS, you should evaluate different physical designs when creating the database. You should also revisit the physical design as the database grows to ensure the design you have chosen still offers the best performance. If possible, make a copy of the database and test it on a backup machine.

In presenting a database design methodology we divide the design process into three main phases:

1. conceptual,
2. logical, and
3. physical database design.

The phase prior to physical design, namely logical database design, is largely independent of implementation details, such as the specific functionality of the target DBMS and application programs, but is dependent on the target data model. The output of this process is a logical data model consisting of an

1. ER/relation diagram,
2. relational schema, and
3. supporting documentation

that describes this model, such as a data dictionary. Together, these represent the sources of information for the physical design process, and they provide the physical database designer with a vehicle for making tradeoffs that are so important to an efficient database design.
Whereas logical database design is concerned with the what, physical database design is concerned with the how. It requires different skills that are often found in different people. In particular, the physical database designer must know how the computer system hosting the DBMS operates, and must be fully aware of the functionality of the target DBMS. As the functionality provided by current systems varies widely, physical design must be tailored to a specific DBMS. However, physical database design is not an isolated activity and there is often feedback between

1. physical,
2. logical, and
3. application design.

For example, decisions taken during physical design for improving performance, such as merging relations together, might affect the structure of the logical data model, which will have an associated effect on the application design.