StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Since you didn't state the purpose of the database, or the requirements, here are some general things, in no particular order:</p> <ol> <li>Small clustered index on each table. Consider making this your primary key on each table. This will be very efficient and save on space in the main table and dependent tables. </li> <li>Appropriate non-clustered indexes (covering indexes where possible) </li> <li>Referential Integrity </li> <li>Normalized Tables </li> <li>Consistent naming on all database objects for easier maintenance </li> <li>Appropriate Partitioning (table and index) if you have the Enterprise Edition of SQL Server </li> <li>Appropriate check constraints on tables if you are going to allow direct data manipulation in the database. </li> <li>Decide where your business rules are going to reside and don't deviate from that. In most cases they do not belong in the database. </li> <li>Run Query Analyzer on your heavily used queries (at least) and look for table scans. This will kill performance. </li> <li>Be prepared to deal with deadlocks. With a database of this size, especially if there will be heavy writing, deadlocks could very well be a problem. </li> <li>Take ample advantage of views to hide query join complexity and potential for query optimization and flexible security implementation. </li> <li>Consider using schemas to better organize data and flexible security implementation. </li> <li>Get familiar with Profiler. With a database of this size, you will more than likely be spending some time trying to determine query bottlenecks. Profiler can help you here. </li> </ol>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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