데이터베이스 테이블 이름 생성기

열을 살펴보기 전에 테이블을 먼저 읽으세요

데이터베이스 테이블 이름은 애플리케이션 코드, SQL, 마이그레이션, 대시보드, 사고 보고서, 팀 토론 등 데이터가 이동하는 모든 곳에서 반복됩니다. 이러한 반복 때문에 테이블 이름 지정은 아키텍처적인 선택입니다. CustomerContactDetails와 같은 엔티티 이름은 레코드를 직접적으로 식별해야 합니다. UserRoleAssignments와 같은 관계 이름은 연결 자체를 명확하게 보여야 합니다. SchemaMigrationLocks와 같은 운영 이름은 테이블이 비즈니스 객체를 나타내는 것이 아니라 작업을 조정하는 역할을 한다는 것을 알려줍니다.

데이터 수명 주기에 맞는 이름을 사용하세요

수명 주기는 종종 가장 중요한 한정자를 제공합니다. PaymentEvents는 추가 전용 기록을 의미합니다. DailySalesRollups는 파생 집계를 의미합니다. StagedCustomers는 유효성 검사를 기다리는 임시로 가져온 레코드를 나타냅니다. ArchivedCustomerRecords는 행이 활성화되지 않았음을 알려줍니다. CacheInvalidationEvents는 파생 데이터와 관련된 조정을 나타냅니다. DataErasureRequests는 개인 정보 보호 및 워크플로 기대치를 나타냅니다. 테이블의 제약 조건, 보존 기간 및 쓰기 패턴이 이러한 용어를 사용하도록 요구하는 경우에만 해당 용어를 선택하십시오.

도메인 용어를 기술적 정확성과 함께 사용하십시오.

좋은 이름은 제품 용어와 데이터베이스 구조를 일치시킵니다. 지원, 재무, 운영 및 분석 부서에서 인식하는 용어를 사용하고, 실제 모호성을 방지해야 하는 경우에만 기술적 한정어를 추가하십시오. InvoicePaymentAllocations는 할당이 최우선 작업인 경우에 유용합니다. CountryCodes는 제한된 조회에 충분합니다. TenantNotificationRules는 모든 행이 테넌트에 속하는 경우에 적합합니다. 데이터는 유지되지만 사라질 수 있는 임시 버전 번호나 서비스 이름과 같은 구현 흔적은 사용하지 마세요.

간단한 명명 규칙 검토

• 중앙 엔티티 또는 이벤트를 먼저 명시하세요.
• 로그, 이벤트, 감사 및 기록은 진정으로 다른 라이프사이클에 사용하세요.
• 스키마 전체에서 조인 테이블 언어의 일관성을 유지하세요.
• 스테이지, 캐시, 아카이브 또는 롤업은 해당 한정자가 실제로 유효한 경우에만 사용하세요.
• 임시 구현 레이블보다 안정적인 도메인 명사를 선호하세요.

다음 마이그레이션을 위한 질문

생성된 이름을 수락하기 전에 조인, 마이그레이션 제목 및 알림에서 테스트하세요. 데이터 소유자를 식별하는지, 현재 상태와 과거 상태를 구분하는지, 다른 테이블에서 이미 동일한 명사를 사용하고 있는지 확인하세요. 그런 다음, 이러한 차이점을 그대로 유지하면서 가장 짧은 이름을 선택하세요.

• 온콜 엔지니어는 이름만 보고 무엇을 추론할 수 있을까요?
• 이 테이블을 가장 가까운 테이블과 구분하는 단어는 무엇일까요?
• 현재 기능이 교체된 후에도 이 이름이 여전히 유효할까요?
• 이름은 어떤 제약 조건이나 수명 주기를 은근히 나타내야 할까요?