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

데이터베이스 테이블 이름이 전달해야 할 메시지

테이블 이름은 아키텍처의 작은 조각입니다. 쿼리, 마이그레이션, 대시보드, 로그, 알림, 문서, 그리고 서로 다른 맥락을 공유하는 사람들 간의 대화에까지 존재합니다. 테이블 이름은 테이블 내의 레코드와 해당 테이블이 소스, 관계, 기록, 캐시, 스테이징 영역 또는 운영 제어용인지 여부를 명확히 보여주어야 합니다. CustomerContactDetails, UserRoleAssignments, SchemaMigrationLocks와 같은 이름은 열을 검사하기 전에 서로 다른 기대치를 전달합니다. 이러한 신호는 추측을 줄이고 더 안전한 변경을 지원합니다.

실제 프로젝트에서 오래 지속되는 테이블 이름 선택

테이블의 역할부터 시작하세요

이 테이블은 무엇을 저장하기 위해 존재하는가라는 한 문장으로 시작하세요. 답은 핵심 엔티티 또는 이벤트와 필요한 경우 구체적인 목적을 명확히 해야 합니다. 레코드에 연락 채널, 동의 상태 또는 청구 ID만 포함되어 있다면 Customer라는 이름은 너무 포괄적일 수 있습니다. CustomerContactDetails는 모든 열을 나열하지 않고도 테이블의 역할을 구체화합니다. 마찬가지로 PaymentEvents는 추가 전용 스트림을 암시하는 반면 PaymentStatuses는 제어된 조회를 암시합니다. 생성기는 열 인식 이름, 이벤트 스트림, 선호도 모델, 분석 롤업 및 기타 반복되는 스키마 패턴을 포괄하므로 정확도 수준을 비교할 수 있습니다.

스키마를 설명하지 않고 관계를 노출하세요

테이블이 주로 레코드를 연결하는 용도로 존재하는 경우 관계에는 눈에 보이는 언어가 필요합니다. 각 행이 자체 날짜, 담당자 또는 범위를 가진 할당을 나타내는 경우 UserRoleAssignments가 UserRoles보다 더 명확합니다. InvoicePaymentAllocations는 결제가 여러 송장에 걸쳐 분할될 수 있음을 나타내고 ArticleTagLinks는 더 간단한 연결을 나타냅니다. 그러나 모든 외래 키를 문장으로 만들 필요는 없습니다. 직접 엔티티 테이블은 여전히 ​​엔티티로 읽혀야 합니다. 관계 자체가 영구적인 개념인 경우에만 참조, 할당, 멤버십, 바인딩 또는 매핑을 추가하세요.

작업을 통해 유용한 단서를 남기세요

프로덕션 시스템은 기록을 축적합니다. MigrationExecutionLogs, CacheInvalidationEvents, FailedPaymentAttempts, DataErasureRequests, ResourceLocks는 일반적인 이름으로는 드러나지 않는 운영 동작을 보여줍니다. 이러한 단서는 엔지니어가 행이 변경 가능한지, 추가 전용인지, 임시적인지, 보존 규칙으로 보호되는지, 또는 동시 작업을 조정하는 데 사용되는지 이해하는 데 도움이 됩니다. 테이블 이름은 제약 조건이나 문서를 대체할 수는 없지만, 무분별한 업데이트에 대한 경고 역할을 할 수 있습니다. 이름에 Archived, Staged, Audit, Rollup, Lock 또는 Request가 포함된 경우 스키마와 수명 주기가 해당 약속을 실제로 지원하는지 확인해야 합니다.

스키마 ID의 일부로서의 명명

스키마는 제품과 마찬가지로 어휘를 개발합니다. 일관된 용어는 조인을 더 쉽게 예측하고 분석가가 권위 있는 데이터를 찾는 데 도움이 됩니다. 프로젝트에서 단수 명사 또는 복수 명사를 사용할지, 조인 테이블이 알파벳 순서 또는 비즈니스 순서를 사용할지, 그리고 기록을 Events, Logs, Audits 또는 Revisions로 설명할지 결정해야 합니다. 안정적인 도메인 언어와 구현 세부 정보를 구분해야 합니다. SubscriptionGracePeriods라는 테이블 이름은 정책 개념을 나타내고, SubscriptionTemp2라는 테이블 이름은 개발 과정의 특정 시점을 나타냅니다.

실용적인 명명 규칙

• 저장된 개념의 이름을 지정하고, 현재 해당 개념을 기록하는 화면이나 서비스의 이름을 지정하지 마십시오.
• Assignments 또는 Memberships와 같은 관계 명사는 관계 자체에 의미가 있는 경우에만 사용하십시오.
• 소스 테이블과 캐시, 롤업, 가져오기, 아카이브 및 이벤트 기록을 구분하십시오.
• 예외를 도입하기 전에 전체 스키마에서 단수 및 복수 규칙을 확인하십시오.
• 제품 및 팀 전체에서 이미 명확하게 사용되는 경우가 아니면 약어 사용을 피하십시오.
• SELECT, JOIN, 마이그레이션 및 알림 내에서 테이블 이름을 읽어 명확성을 유지하십시오.

테이블 이름을 명확하게 하는 질문

생성된 각 결과를 자동 답변이 아닌 설계 질문으로 취급하십시오. 테이블의 소유권, 기록 주체, 레코드 보존 기간, 행 삭제 가능 여부, 그리고 가장 자주 사용되는 쿼리 유형 등을 고려하세요. 제안하는 테이블 이름을 주변 테이블 및 코드에서 사용되는 단어와 비교해 보세요. 최종적으로 선택할 테이블 이름은 혼동을 방지할 만큼 구체적이면서도 반복적으로 사용하기에 간결하고, 향후 기능 추가 요청에도 안정적으로 유지될 수 있어야 합니다. 생성기를 사용하여 타당한 옵션을 비교하고 장단점을 파악하세요.

• 새로운 엔지니어가 행이 현재 상태인지 과거 이벤트인지 알 수 있을까요?
• 이름이 다대다 관계를 과장하지 않고 명확하게 나타낼 수 있을까요?
• 이 테이블이 캐시, 스테이징 테이블 또는 조회 카탈로그와 혼동될 수 있을까요?
• 삭제, 보존 또는 불변성에 대해 독자에게 경고하는 수명 주기 용어는 무엇일까요?
• 열이나 워크플로 단계가 하나 더 추가되더라도 이름이 여전히 적합할까요?
• 선택한 명사가 제품, 지원 및 분석 팀에서 사용하는 용어와 일치할까요?