테이블 이름 앞에 접두사를 붙이는 것은 예전에는 인기 있는 방식이었습니다. 현재 추세는 접두사 추가를 포기하는 것입니다. 왜냐하면 접두사 추가가 가져오는 이점이 가져오는 문제보다 훨씬 적기 때문입니다. 많은 경우, 교차 데이터베이스 디자인은 테이블 접두사 디자인보다 더 유연하고 실용적이며, 접두사 디자인(특히 혼합 상황에서)으로 인한 혼란과 문제는 많은 초보자에게 가장 큰 문제입니다. 그러니 주의하시기 바랍니다.
프로젝트에 100개 이상의 테이블이 있으면 해당 테이블을 사용해야 하는 이유를 이해하게 될 것입니다.
이상적으로는 user_tabel1을 user.table1로 작성할 수 있습니다(여러 라이브러리 생성) 문제는 많은 개발자가 (하나의 라이브러리에만 연결할 수 있는) 많은 프레임워크를 포함하여 단순히 추가, 삭제, 수정 및 확인만으로 데이터베이스를 알고 있다는 것입니다.
예를 들어, Oracle의 가장 고전적인 scott 인스턴스는 scott에 부서 및 부서 직원 목록이 있고, hr(다른 인스턴스)에는 부서 목록이 있는 제품 인스턴스도 있습니다. hr 인스턴스에는 a list of scott.emp에는 선택 권한이 있지만 업데이트 권한은 없습니다
개인적으로는 이 디자인이 데이터 보안을 향상시키고(인스턴스가 공격을 받고 크랙이 발생하면 모든 데이터가 노출되지 않음) 논리적 명확성이 크게 향상되었다고 생각합니다. 그러나 우리가 자주 보는 것은 모든 개발자 테이블이 하나의 라이브러리에 배치되어 있다는 것입니다.
테이블 이름 앞에 접두사를 붙이는 것은 예전에는 인기 있는 방식이었습니다. 현재 추세는 접두사 추가를 포기하는 것입니다. 왜냐하면 접두사 추가가 가져오는 이점이 가져오는 문제보다 훨씬 적기 때문입니다. 많은 경우, 교차 데이터베이스 디자인은 테이블 접두사 디자인보다 더 유연하고 실용적이며, 접두사 디자인(특히 혼합 상황에서)으로 인한 혼란과 문제는 많은 초보자에게 가장 큰 문제입니다. 그러니 주의하시기 바랍니다.
관리가 쉽습니다
동일한 데이터베이스에 여러 프로젝트를 넣으면 유용할 것입니다
프로젝트 1 사용자 테이블 - p1_user
프로젝트 2 사용자 테이블 - p2_user
이렇게 말하면 이해하실 거예요
그냥 디자인 습관일 뿐이에요. 일반적으로 동일한 라이브러리에 있는 서로 다른 시스템 테이블을 구별하기 위해 생성됩니다.
사진과 같이 접두어가 없는 테이블이 배경 관리 시스템의 테이블입니다. wms 접두사가 붙은 테이블은 wms 시스템의 테이블입니다
솔직히 데이터베이스에 따라 테이블 종류를 나누는 게 더 적절해요. 접두어가 정말 번거롭거든요
접두사는 매우 유용합니다. 예를 들어
에 대한 모든 것을 알고 싶을 때입니다.user
的表,直接show tables like '%user%'
就可以了,用mysql
명령줄특히 플러그인이나 모듈이 많은 프로젝트의 경우 이러한 접두사를 추가하면 데이터베이스 테이블 및 기타 작업의 일괄 처리에도 도움이 됩니다
동일한 데이터베이스에 있는 서로 다른 프로젝트의 데이터 테이블을 사용하여 모든 프로젝트를 구별하는 데 사용됩니다
테이블 이름의 접두사는 단지 명명 규칙일 뿐이며 함수 구현에는 영향을 미치지 않습니다.
더 복잡한 시스템에서는 테이블 이름 접두사를 통해 테이블의 모듈과 분류를 대략적으로 이해할 수 있으며, 이는 일상적인 개발 및 운영 및 유지 관리 시 더 편리해 보이며, 신규 사용자도 시스템 데이터 구조를 이해할 때 따라야 할 규칙이 있습니다.
개인적으로는 이 접근 방식에 동의합니다. 비용은 매우 저렴하지만 나중에 운영 및 유지 관리에 편리합니다.
데이터 테이블이 하나의 데이터베이스에 있고 데이터 테이블이 많으면 구별이 매우 간단합니다
프로젝트에 100개 이상의 테이블이 있으면 해당 테이블을 사용해야 하는 이유를 이해하게 될 것입니다.
이상적으로는 user_tabel1을 user.table1로 작성할 수 있습니다(여러 라이브러리 생성)
문제는 많은 개발자가 (하나의 라이브러리에만 연결할 수 있는) 많은 프레임워크를 포함하여 단순히 추가, 삭제, 수정 및 확인만으로 데이터베이스를 알고 있다는 것입니다.
예를 들어, Oracle의 가장 고전적인 scott 인스턴스는
scott에 부서 및 부서 직원 목록이 있고, hr(다른 인스턴스)에는 부서 목록이 있는 제품 인스턴스도 있습니다.
hr 인스턴스에는 a list of scott.emp에는 선택 권한이 있지만 업데이트 권한은 없습니다
개인적으로는 이 디자인이 데이터 보안을 향상시키고(인스턴스가 공격을 받고 크랙이 발생하면 모든 데이터가 노출되지 않음) 논리적 명확성이 크게 향상되었다고 생각합니다.
그러나 우리가 자주 보는 것은 모든 개발자 테이블이 하나의 라이브러리에 배치되어 있다는 것입니다.
(위 내용은 개인적인 이해입니다)