You can do several things:
Create views for performance. A view is a contract of intention that tells the RDBMS "I will be running this query very often". When you do that the RDBMS optimizes the access to this data.
Create views for simplicity and tuning. You create views in order to split the big solution into smaller solutions. This way you can measure exactly where the bottleneck is and try to improve the problematic areas.
Create denormalized tables ( materialized views ). Sometimes it pays back to create summarized tables in order to make certain reports faster, especially of data that is not transactional.
Create a non-transactional database or datawarehouse for queries. Most RDBMS has ways of tuning a special database for queries when this databases is not transactional, ie, it's not being hit continuosly with inserts or updates. The whole set of tuning configurations if different when the database has this purpose. It's more efficient than a general purpose database.
Put most queried tables in faster disks. Move most queried tables in tablespaces located in better, faster disks and better connections (SAN). Move not so important tables to slower, cheaper disks and not so fast connections.
Use structure programming techniques to split your stored procedures into smaller ones, so you can keep complexity at bay. That way you can concentrate better on improving performance once you don't have all the complecity in your face all the time.
Use queries with binding variables avoiding concatenated ones. That way the RDBMS is able to cash them in the query area and they run faster because you save parsing time and planning time.
Remember that your DBA is your friend, and he/she can do a lot to improve database performance. Don't rely solely on your programming skills. You are not alone.