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.
--> 테이블 이름에 복수형 보다는 단수형 이름을 사용해라 (난 영어를 잘 못해서 항상 단수형을 써왔지만... 오픈소스 tutorial이나 예제에서는 복수형을 사용하는 경우를 자주 보았는데???)
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.).
--> 불필요한 접두사, 접미사를 사용하지 마라 (최근에 와서는 동감함, simple is best!!!)
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 ...).
--> 모든 테이블에 정수값을 갖는 ID 컬럼을 사용해라. 만약 지금 당장 필요하지 않을 지라도 미래에는 필요하게 될 것 이다.
Choose columns with the integer data type (or its variants) for indexing. varchar column indexing will cause performance problems.
--> 인덱스를 위한 컬럼의 데이터 타입은 정수형 데이터 타입을 사용해라. varchar 컬럼 인덱스는 성능문제를 야기할 수 있다.(도메인 모델에 따라서 varchar에도 index를 사용해야만 하는 경우가 있다고 생각함)
Use bit fields for boolean values. Using integer or varchar is unnecessarily storage consuming. Also start those column names with “Is”.
--> boolean 값을 위해서 bit 필드를 사용해라, 정수형이나 varchar를 사용하는 것은 스토리지 사용량을 늘린다. 또한 컬럼이름은 "Is"로 시작해라.
Provide authentication for database access. Don’t give admin role to each user.
--> 데이터 베이스에 접근할 수 있는 별도의 권한을 제공해라, 절대로 admin 권한을 각각의 사용자에게 주지 마라
Avoid “select *” queries until it is really needed. Use "select [required_columns_list]" for better performance.
--> 꼭 필요한 것이 아니라면
"select * " 쿼리문을 사용하지 마라. 성능을 위해서는
"select [required_columns_list]" 을 사용해라(두문장에 성능 차이가 그렇게 심한가??? 일반적으로 Hibernate와 같은 ORM을 사용하면 'select *' 문은 거의 사용되지 않기는 하지만... MyBatis와 같이 직접 SQL문을 사용해야 하는 경우는 "select *" 문이 편하던데???)
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.4
--> 어플리케이션 코드가 충분히? 크다면 ORM 프레임워크를 사용해라. 성능이슈는 설정값을 통해서 해결할 수 있다.
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.
--> 대용량 이거나 민감하고, 미션 크리티컬한 DB 시스템이라면, failover, 클러스터링, 자동백업, 복제(리플리케이션)등과 같은 재해복구와 보완 서비스를 사용해라.
Use constraints (foreign key, check, not null ...) for data integrity. Don’t give whole control to application code.
--> 데이터 무결성을 위해서 DB constraint를 사용해라. 모든 것을 어플리케이션 코드로 처리하려 하지 마라.
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.
--> 부실한 DB 문서는 악마다. DB 설계를 위한 ER 스키마 및 명령어를 문서화하고, 트리거와 저장프로시져 혹은 기타 스크립트의 경우 주석을 작성해라.
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.
--> 대용량 테이블에서 자주 사용되는 쿼리를 위해서 index를 사용해라, 쿼리 분석 도구를 사용해서 인덱스를 잘 정의해서 사용해라. 페이징 처리와 같은 특정영역의 ro들w를 커리하는 경우, 일반적으로 clustered index들이 더 좋다. 반면 특정 데이터를 쿼리하는 경우는 non-clustered index들이 더 좋다.
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.
--> DB 서버와 Web application 서버는 별도의 물리 서버에 배치해라. 그것은 더 낳은 보완성과 성능을 제공할 것이다.
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.
--> 이미지 혹은 blob 데이터 컬럼은 자주 조회되는 테이블에 정의하면 절대로 않된다. 그것은 성능이슈를 야기 시킬 것이다. 그런 데이터들은 반드시 테이블을 분리하거나 파일 시스템을 사용해라.(내맘대로 해석...)
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.
--> 정규화는 잘 사용되어져야 한다. 비정규화는 데이터를 중복 시키고, 잘못된 정규화는 테이블간의 과도한 join문을 발생시킨다. (너무 당연한 소리이지만... 정답을 찾기 어려운 문제다. 그때 그때 달라요!!!)
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.
--> DB 모델링과 설계에 가능한 많은 시간을 사용해라. 그렇지 않고 설계 시간을 줄이려다가는 유지보수가 어려워지거나 재설계가 필요해질 수 있다.
