development	Many multi-tier applications nowadays use the database as a pure data repository. On the question "Who ensures the data consistency between these two tables?", one usually gets the answer: "This is being ensured by the application server!". Tables are being addressed via object-relational mappings and the entire program logic is implemented outside of the database. In our opinion, this approach bears at least two risks: On the one hand, no application can enforce data consistency and integrity like a database, that was designed specially for this purpose, can. It is sufficient to insert or update data directly via a loader or a database development tool to render the best application server useless. On the other hand, a database offers optimized data access techniques and patterns which take into consideration the storage of data, their contents, as well as connections between data -- information usually not available outside the database. An - optimized - join runs nowhere faster than in a database. A database can do far more than administrate extents. Starting with data consistency, going through performance optimization, and ending with embedding procedural objects, a database offers powerful instruments. This is why our approach is to use the features a database offers - including integrated development environments - to the maximum of their capabilities. This means for example: Implement those parts of the program logic inside the database, which run more efficiently and safely there. Use normalized data structures. De-normalized tables should be used only on purpose and targeted, for example on the higher levels of data warehouses for performance enhancement. Constraints are powerful instruments for enforcing data integrity and consistency, which a database validates very efficiently. Therefore, constraints - including relations (foreign keys) - should be used, whenever possible. All object types available in a database - indexes, views, procedures, triggers etc. - should be used. Performance tuning should be done actively. No - complex - statement should go into production before its execution plan was analyzed and found optimal; statistics should be gathered for all tables, indexes, and relevant columns, etc. Parallelism should be used whenever the database offers it and resources are available - for example in Selects, Create Index statements, etc. . . .