Вы находитесь на странице: 1из 3

Best Practice to Architect Database Design

1. Normalize the database design that minimize redundancy of records .(follow at


least 1, 2 form )
2. Use well defined names for tables and fields, i.e. SalesOrder, not order.
3. Use the singular, i.e. SalesOrder not SalesOrders.
4. Use leading capitals for name, i.e. SalesOrder not salesorder.
5. Avoid spaces and other punctuation, i.e. SalesOrder not [sales order] or [tblSales
order]. This avoids having to put [] around the name all the time.
6. Use a single field primary key (PK). Even though you may have other fields
that could compound to give you the PK, we find it better not to.
7. Use ID as the name of the PK field where possible, i.e. ID.
8. Use the name of the table appended with ID as the name of the Foreign Key
field where possible, i.e. SalesOrderID.
9. Use bit fields to store Boolean yes/no values and start the name with Is, i.e.
IsEnabled.
10. For tables that store type information, i.e. a lookup-list, append the word Type, i.e.
CurrencyType or CountryType.
11. Add audit fields so we know who created and when and who modified and
when (for transactional tables)
12. For look up/definiations tables, add SortOrder field which can be used to sort listing
data.
13. Use the database diagrams to visualize schema. This makes creating relationships a
breeze.
14. Use indexes to speed up queries.
15. Use unique constraints/indexes. Avoids having duplicate data in the database
where it shouldn't be.
16. When required, add a field that is a computed column that you can define. We point
them to other fields in the table and always use this field as the display field for dropdowns
etc. If we need to change it later, we just change the formula in the computed field in SQL
Server.
17. prefix with stored procedure name like usp_ and with table name like tbl_ will not be
used. Schemas will be used instead to conceptually organize related stored procedures and
tables etc.

Schema: You can define schema in sql server to conceptually group related objects through
schema and then an object can be invoked as a child of its schema as:
SchemaName.ObjectName.

Example: To get all sales orders we can define a stored procedure with the name 'GetAll'
under 'SalesOrder' Schema and can be invoked like this: SalesOrder.GetAll

18. A table for error handling should be created to log errors with name
‘ErrorLog’. All application errors/exceptions must be logged in this table.
DATA TYPE USAGE GUIDELINES

1. Use nvarchar fields to ensure all languages are catered for.


2. Use varchar(max) when needed, avoid ntext or image unless really needed.
3. Don’t store images or binary data in DB unless any very special scenario

ADDITIONAL GUIDELINES

19. Don’t delete, instead use an IsDeleted bit field to mark the record as deleted. Ensure
all data is filtered by this.
20. Add a couple of extra fields where needed, IsHidden and IsEnabled, that allow the
record to be filtered by the admin and the user, i.e. as an admin, I don't want a user to login
any more I set the IsEnabled to false, if later want them to login, I simply flip the flag. The
IsHidden can be used to filter items that appear in dropdown lists, for example, without
deleting it.
21. Add an autoincrement field, but not for use as the PK. This can be useful when
creating invoices, for example, and you need a visual number for the user.
22. Use functions for repeated code, i.e. we have a suite of functions that return 1st
day of month, 1st day of quarter, 1st day of year, etc.
23. When we have some functionality that requires speed, put it in the database. Move it
out of the application to a stored procedure; you gain speed but loose the strongly typed
environment.
24. Write your stored procedures so they can be tested and benchmarked.

Вам также может понравиться