The design of any application depends on the foundation of its data model. We must all accept the simple fact that the decisions made during the data modeling phase will determine the overall success of the application.  

Before we address any specific data modeling topics or problems, we must talk about the philosophy that will provide the basis for any solutions presented here. 

First, it is important to have a good understanding of the rules of performance tuning:

1. Tune the design (fix the data model, if it’s not too late)
2. Tune the application
3. Tune Memory
4. Tune IO
5. Tune contention
6. Tune operating system

What are the data model guidelines that I follow to avoid breaking the performance tuning rules?

1. There are no absolutes. All decisions you will make are situational and need to consider the unique application requirements. If you blindly follow a philosophy, including the one presented here, I am sorry to inform you that nothing but luck will be available for you when designing a data model that is both scalable and high performance.
2. Design for the database platform.  Use the features of the RDBMS you selected, the dream of a data model that works great on all database platforms will never be realized in your life time.
3. General purpose ORMs do not create SQL optimized for your application. You will never be lucky enough to be working on an application where the auto generated SQL meets all requirements.
4. If the applications fails, it will be either the data model’s or the application design’s fault not the database platform selected. 
5. While designing the data model visualize all queries that will be run, how new data will be inserted, and the data manipulations that will be done in various use case scenarios.
6. You must know how the query optimizer works for the RDBMS platform you are designing for. 
7. All applications will SELECT, INSERT, UPDATE, DELETE data. Understand what the application needs to do, who is doing it, and how it will be done.
8. UPDATE and DELETE statements will always need to search for data, INSERTS not so much.
9. Users are more patient when they give data, but not as much when they are selecting data. Generally speaking, if a design decision must be made between INSERT or SELECT performance, error on benefiting the SELECT.
10. Advise the development team on how best to use “your” data model, or better yet help them build the data access layer (DAL).