Scribd Logo
Upload

Welcome to Scribd!

  • 250 views

    Database Design Best Practices

    Uploaded by

    cicaza
    Use well defined and consistent names for tables and columns. Avoid unnecessary prefixes or suffixes for table names. Avoid "select (c) queries until it is really needed. Use an ORM (object relational mapping) framework (i.e. Hibernate, iBatis.) for consuming.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd

    Database Design Best Practices

    Uploaded by

    cicaza
    250 views2 pages
    Use well defined and consistent names for tables and columns. Avoid unnecessary prefixes or suffixes for table names. Avoid "select (c) queries until it is really needed. Use an ORM (object relational mapping) framework (i.e. Hibernate, iBatis.) for consuming.

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Use well defined and consistent names for tables and columns. Avoid unnecessary prefixes or suffixes for table names. Avoid "select (c) queries until it is really needed. Use an ORM (object relational mapping) framework (i.e. Hibernate, iBatis.) for consuming.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    250 views2 pages

    Database Design Best Practices

    Uploaded by

    cicaza
    Use well defined and consistent names for tables and columns. Avoid unnecessary prefixes or suffixes for table names. Avoid "select (c) queries until it is really needed. Use an ORM (object relational mapping) framework (i.e. Hibernate, iBatis.) for consuming.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 2

    CodeBalance: 20 Database Design Best Practices

    http://codebalance.blogspot.com/2011/07/20-database-design-best-pr...

    20 Database Design Best Practices


    Posted on 2011-07-24 by CB

    39

    1. Use well defined and consistent names for tables and columns (i.e. School, StudentCo urse, CourseID ...). 2. Use singular for table names (i.e. use StudentCourse instead of StudentCourses). Tab collection of entities, there is no need for plural names. 3. Dont use spaces for table names. Otherwise you will have to use {, [, etc. characters to define tables (i.e. for accesing table Student Course you'll write Student Course. StudentCourse is muchetter). b 4. Dont use unnecessary prefixes or suffixes for table names (i.e. use School insteadof TblSchool, SchoolTable etc.). 5. Keep passwords as encrypted for security. Decrypt them in application when required. 6. Use integer id fields for all tables. If id is not required for the time being, it m ay be required in the future (for association tables, indexing ...). 7. Choose columns with the integer data type (or its variants) for indexing. varchar co cause performance problems. 8. Use bit fields for boolean values. Using integer or varchar is unnecessarily storage those column names with Is. 9. Provide authentication for database access. Dont give admin role to each user. 10. Avoid select * queries until it is really needed. Use "select [required_columns_li better performance. 11. Use an ORM (object relational mapping) framework (i.e. hibernate, iBatis ...) if app lication code is st]" for consuming. Also start lumn indexing will le represents a

    big enough. Performance issues of ORM frameworks can be handled by detailed configuratio parameters. n 12. Partition big and unused/rarely used tables/table parts to different physical storag performance. 13. For big, sensitive and mission critic database systems, use disaster recovery and se like failover clustering, auto backups, replication etc. 14. Use constraints (foreign key, check, not null ...) for data integrity. Dont give wh ole control to application code. 15. Lack of database documentation is evil. Document your database design with ER schema s and instructions. Also write comment lines for your triggers, stored procedures and other scripts. 16. Use indexes for frequently used queries on big tables. Analyser tools can be used to determine where indexes will be defined. For queries retrieving a range of rows, clustered indexes are usual ly better. For curity services es for better query

    1 de 4

    26/07/2011 08:05 p.m.

    CodeBalance: 20 Database Design Best Practices

    http://codebalance.blogspot.com/2011/07/20-database-design-best-pr...

    point queries, non-clustered indexes are usually better. 17. Database server and the web server must be placed in different machines. This will p rovide more security (attackers cant access data directly) and server CPU and memory performance will be of reduced request number and process usage. 18. Image and blob data columns must not be defined in frequently queried tables because of performance better because

    issues. These data must be placed in separate tables and their pointer can be used in queried tables. 19. Normalization must be used as required, to optimize the performance. them will get worse performance. 20. Spend time for database modeling and design as much as required. Otherwise saved(!)design time will cause (saved(!) design time) * 10/100/1000 maintenance and re-design time.
    This entry was posted in Databases and Data Mining Bookmark the permalink. .

    Under-normalization will cause

    excessive repetition of data, over-normalization will cause excessive joins across too many tables. Both of

    13 Responses to

    20 Database Design Best Practices

    Tim Garrett says:


    7/25/2011 7:59 AM

    Very thoughtful post. On point #5, unless your usage requires sending a password to another system, I would recommend hashing the stored passwords rather than encrypting them. Anytime an encry ption key is available in memory or on disk, the passwords are probably quite easily accessed in the event of a hack. Your system might not have critical data, but a lot of users will use the exact same password in every oth er banking and financial site they visit. If you can, help protect users from themselves (and inform them of better tactics wh en given the chance).

    Anonymous

    says:

    7/25/2011 10:22 AM

    Hash. Passwords. With a salt. With a a hashing method that's slow (in computer terms ).

    Clay says:
    7/25/2011 3:53 PM

    For 18, if this is SQL Server, there are options for storing blob and large text dat a out of row. http://msdn.microsoft.com /en-us/library/ms189087.aspx. sp_tableoption N'MyTable', 'large value types out of row', 'ON'

    Anonymous

    says:

    7/26/2011 12:01 AM

    #7 I wouldn't say so. What is the difference between 100 and 'BAA' in terms of index ing?

    CB says:
    7/26/2011 12:17 AM

    There is I/O difference. A varchar column will take

    2 de 4

    26/07/2011 08:05 p.m.

    You might also like

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy