Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Personally I think you should read a book on performance tuning before beginning to model a database. The right design can make a world of difference. If you are not expert in performance tuning, you aren't qualified to design a database.</p> <p>These books are Database specific, here is one for SQl Server. <a href="http://rads.stackoverflow.com/amzn/click/1430219025">http://www.amazon.com/Server-Performance-Tuning-Distilled-Experts/dp/1430219025/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1313603282&amp;sr=1-1</a></p> <p>Another book that you should read before starting to design is about antipatterns. Always good to know what you should avoid doing. <a href="http://rads.stackoverflow.com/amzn/click/1934356557">http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&amp;ie=UTF8&amp;qid=1313603622&amp;sr=1-1</a></p> <p>Do not get stuck in the trap of designing for flexibility. People use that as a way to get out of doing the work to design correctly and flexible databases almost always perform badly. If more than 5% of your database design depends on flexibility, you haven't modeled correctly in my opinion. All the worst COTS products I've had to work with were designed for flexibility first.</p> <p>Any decent database book will discuss normalization. You can also find that information easily on the web. Be sure to actually create FK/PK relationships.</p> <p>As far as naming columns, pick a standard and stick with it consistently. Consistency is more important than the actual standard. Don't name columns ID (see SQL antipatterns book). Use the same name and datatypes if columns are going to be in several different tables. What you are going for is to not have to use functions to do joins because of datatype mismatches. </p> <p>Always remember that databases can (and will) be changed outside the application. Anything that is needed for data integrity must be in the database not the application code. The data will be there long after the application has been replaced.</p> <p>The most important things for database design:</p> <ul> <li>Thorough definition of the data needed (including correct datatypes) and the relationships between pieces of data (including correct normalization)</li> <li>data integrity</li> <li>performance</li> <li>security</li> <li>consistency (of datatypes, naming standards etc.)</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload