Last active
August 23, 2017 08:28
-
-
Save cham11ng/88e2c2a5674a3b2f7800a92b17737cff to your computer and use it in GitHub Desktop.
List of Guides
- Use lowercase: Will help on speed typing, avoid mistakes dues to case sensitivity e.t.c
- No space – use underscore instead
- No numbers in name only alpha English characters
- Valid understandable names like blog, ecommerce e.t.c but not like project, james, e.t.c
- Name should be self explanatory
- Names should not be more than 64 characters.
- Avoid prefix
- Name can be both singular and plural but database represent one database so it should be singular if possible.
- Avoid prefix if possible.
-
Lower case table name: Mysql is usually hosted in Linux server which is case sensitive so for best practice table name should be all lower case. Many PHP or other programming framework auto detect or auto generate class based on table names and most of them expect lower table name.
-
Table name is Singular: We think table holds so may things like user table holds many users in the table, so name should be plural but table is a single entity as Model is only one so its odd to have plural table name. So name your table like user, invoice, comment.
-
Prefix in table name: I have seen many times that table name has prefix usually db name or project name. Some time it is necessary to have prefix as in hosting envirnment we have many tables in one db to overcome limitation of db by hosting providers. But try to aviod them. Name should be small and meaningful rather than long menaning less names. If we cant avoid prefix then we can fix it by php classes.
Use all above cases i.e lowercase, no space, no numbers, and avoid prefix.
- Choose short and one or two words as possible.
- Field names should be understand able eg: price, company_name, e.t.c
- Primary column name: Primary key can be id, or table name _id. Its depends on your own choice but for me, I prefer id as its self explanatory.
- Avoid using reserve word as field name: order, date, name are reserve word for database avoid using it. You can add prefix to these names to make it understandable like user_name, signup_date e.t.c
- Avoid using column with same name as table name. This can cause confusion while writing query.
- Do define foreign key on database schema.
- Avoid abbreviated, concatenated, or acronym-based names
- Foreign key column must have table name with their primary key, eg: blog_id represents foreign key id from table blog.
- Avoid semantically – meaningful primary key names. A classic design mistake is creating a table with primary key that has actual meaning like ‘name’ as primary key. In this case if some one change his name then relationship with other table will be effected and name can be repetitive (not unique).
- Use well defined and consistent names for tables and columns (e.g. School, StudentCourse, CourseID …).
- Use singular for table names (i.e. use StudentCourse instead of StudentCourses). Table represents a collection of entities, there is no need for plural names.
- Don’t 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 much better).
- Don’t use unnecessary prefixes or suffixes for table names (i.e. use School instead of TblSchool, SchoolTable etc.).
- Keep passwords as encrypted for security. Decrypt them in application when required.
- Use integer id fields for all tables. If id is not required for the time being, it may be required in the future (for association tables, indexing …).
- Choose columns with the integer data type (or its variants) for indexing. varchar column indexing will cause performance problems.
- Use bit fields for boolean values. Using integer or varchar is unnecessarily storage consuming. Also start those column names with “Is”.
- Provide authentication for database access. Don’t give admin role to each user.
- Avoid “select *” queries until it is really needed. Use “select [required_columns_list]” for better performance.
- Use an ORM (object relational mapping) framework (i.e. hibernate, iBatis …) if application code is big enough. Performance issues of ORM frameworks can be handled by detailed configuration parameters.
- Partition big and unused/rarely used tables/table parts to different physical storages for better query performance.
- For big, sensitive and mission critic database systems, use disaster recovery and security services like failover clustering, auto backups, replication etc.
- Use constraints (foreign key, check, not null …) for data integrity. Don’t give whole control to application code.
- Lack of database documentation is evil. Document your database design with ER schemas and instructions. Also write comment lines for your triggers, stored procedures and other scripts.
- 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 usually better. For point queries, non-clustered indexes are usually better.
- Database server and the web server must be placed in different machines. This will provide more security (attackers can’t access data directly) and server CPU and memory performance will be better because of reduced request number and process usage.
- Image and blob data columns must not be defined in frequently queried tables because of performance issues. These data must be placed in separate tables and their pointer can be used in queried tables.
- Normalization must be used as required, to optimize the performance. Under-normalization will cause excessive repetition of data, over-normalization will cause excessive joins across too many tables. Both of them will get worse performance.
- 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment