축약 형 테이블 이름을 사용해야하는 이유가 있습니까?

우리는 데이터베이스 테이블 이름을 읽기가 끔찍하고 어디에 저장되어 있는지에 대한 문서가없는 벤더 애플리케이션의 데이터베이스 설정을 사용하고 있습니다. 독점 앱에서 테이블 구조를 난독 화하려는 이유를 알 수 있지만이 응용 프로그램 (Enterprise Resource Planning)의 판매 포인트 중 하나는 사용자 정의 기능이었습니다.

테이블 이름은 aptrx (Accounts Payable Transactions) 및 apmaster_all과 비슷합니다 (흥미롭게도 이것은 vendor 테이블입니다). 매우 복잡한 데이터베이스이므로 컨벤션에 논리가 있는지 또는 의도적으로 또는 다른 방식으로 난독 화되었는지 궁금합니다.

내가 아는 한, 테이블 이름의 길이는 성능에 눈에 띄지 않습니다. 맞습니까? 데이터베이스는 매우 복잡하므로 (수백 개의 테이블) 정렬이 의미가 있지만 AccountsPayableTransactions가 aptrx보다 선호되지 않는 이유는 상상할 수 없습니다.

Oracle은 테이블 이름을 30 자로 제한했습니다. 원래 16 비트 환경을 기반으로 한 레거시 문제라고 생각합니다.
모든 이름을 데이터 사전에 저장하고 쿼리를 위해 구문 분석해야하기 때문에 테이블 이름의 길이는 성능에 약간의 영향을 줄 수 있지만 히트를 측정 할 수는 없다고 생각합니다.

짧은 테이블 이름의 더 중요한 효과는 작업하기가 어렵다는 것입니다. 나도 짧은 이름으로 엔터프라이즈 데이터베이스 스키마를 유지해야합니다. 테이블 이름이 짧은 이유는 없습니다. 유지 관리가 쉬워 매번 난독 화나 오래된 DOS 습관보다 우선합니다.

나는 여전히 말하거나 정교해야 할 두 가지가 있다고 느낍니다.

1. 이름을 지정하는 것은 들리는 것처럼 사소하지 않습니다.

   Computer Science에는 두 가지 어려운 문제인 캐시 무효화 및 이름 지정 문제가 있습니다. 필 칼튼

2. 의미없는 짧은 이름은 항상 나쁘지만 긴 이름은 항상 좋은 것은 아닙니다. 뇌에는 내장 된 tl; dr 임계 값이있어 놀랍도록 낮습니다. 일반적으로 30 자이면 충분하지만 RDBMS는 예외적 인 경우에 더 많은 것을 허용하기를 원합니다 (언어와 마찬가지로 긴 이름은 제약 조건 이름과 같이 자주 말하지 않는 것들에 더 유용합니다) 짧은 이름은 우리가 항상 쿼리하는 테이블에 더 유용합니다)

나는 항상 이름을 선택하는 데 너무 적은 시간을 보내고 싶은 유혹을 느낍니다. 나중에하면 후회합니다. 이름을 바꾸는 일은 거의 일어나지 않습니다.

게으름. IntelliSense 및 타사 옵션을 사용하면 타이핑을 정당화하기가 어렵습니다. 오히려 그 이름에는 의미 있고 읽기 쉬운 단어가 있습니다.

테이블 이름은 aptrx (Accounts Payable Transactions) 및 apmaster_all과 비슷합니다 (흥미롭게도 이것은 vendor 테이블입니다). 매우 복잡한 데이터베이스이므로 컨벤션에 논리가 있는지 또는 의도적으로 또는 다른 방식으로 난독 화되었는지 궁금합니다.

잘 알려진 약어가 일반적으로 철자를 쓰는 데 선호됩니다. 약어가 일부 사람들에게 잘 알려져 있지만 사람들이 충분하지 않은 경우 약어를 중지하고 코드라고 부르기 시작합니다.

약어는 제한이 엄격한 플랫폼에서 공간을 절약하지만 30 년 전보다 덜 중요합니다. (1980 년대의 시스템에서 테이블 이름으로 6 자 또는 8 자로 제한 한 것을 기억합니다.)

약어는 일반적으로 약어가 잘 수행되는 한 테이블 이름과 열 이름을보다 쉽게 ​​읽을 수있게합니다. 하루 종일 AP 코드를 작업했다면 "accounts_payable_transactions.invoice_number"보다 "ap_trx.inv_num"과 같은 열 이름을 읽는 것이 좋습니다. (나는 밑줄을 좋아한다.) 긴 이름을 입력하는 것은 좋은 텍스트 편집기에서 큰 문제가되지 않는다.

회계 시스템에서 "ap"와 "trx"는 모두 잘 알려진 약어입니다. 기타 채권, 총계정 원장 및 일반 분개에 대한 "ar", "gl"및 "gj"가 있습니다.

잘 설계된 시스템에서 "aptrx"라는 테이블에서 미지급금 거래를 발견하면 artrx에서 미수금 거래, gltrx의 총계정 원장 거래 등을 찾을 수 있기를 바랍니다. "apmaster_all"에 약간의 수수께끼가 있지만 "armaster_all"도 발견 한 경우 첫 번째는 모든 공급 업체 (활성 또는 비활성 공급 업체가 아닌)를 보유하고 두 번째는 모든 고객을 유사하게 보유한 것으로 가정합니다.

다른 문제 영역에서는 잘 알려진 다른 약어가 있습니다. 주소 지정에서 주소에 대한 "addr", 거리에 대한 "st", 미국 우편 서비스에 대한 "usps", United Parcel Service에 대한 "ups", 카운티에 대한 "cty", 구역에 대한 "zip"과 같은 약어가 있습니다. 코드 등

나는이 난독 화를 부르지 않을 것입니다. 미지급금 트랜잭션이 "cdrs21"라는 이름의 테이블에 저장 한 경우에, 나는 전화 줄 이 난처합니다. (내가 한 번 모든 메인 프레임 어셈블러 모듈을 그런 식으로 명명 한 회사에서 일했지만, 난독 화가 아닌 문자 제한입니다.)

그러나 유용한 데이터베이스가 커지고 데이터베이스가 커지면 문제가 발생합니다. 데이터베이스에 문제 도메인을 추가하면 잘 알려진 약어가 충돌하는 상황이 발생합니다. 미디어를 다루는 경우 "ap"는 "Associated Press", "alternative press"또는 "advance Place"를 축약 할 수도 있습니다. 그런 경우 약어를 포기하거나 코드로 전환해야합니다. 조직이 클수록 (그리고 데이터베이스가 클수록) 코드를 더 자주 찾습니다.

"나의 신,이 고글은이 끔찍한 명명 규칙에 대해 아무 것도하지 않는다"는 이야기로 시작됩니다. 마지막 환경의 데이터 관리 팀은 축약 된 테이블 이름을 사용하는 이유는 테이블 및 열에 대해 18 자의 DB2 제한 (z / os 및 SQL Server에 DB2가 있음)이라고 설명했습니다. 나는 이것이 IBM 사이트의 문서에 부정확하다고 지적했다. 그런 다음 데이터베이스와 대화해야 MF 기수에 의해 반증 될 경우를 대비하여 COBOL 문제 (예 : COBOL이 적극적으로 개발 됨)라고 밝혔습니다. 마지막으로 그들의 답변은 우리의 출판 표준이었습니다.

우리는 표준위원회에 길이를 18 자에서 32 자로 늘리고 30 자 제한을 청원했습니다. 그 결과 테이블이 쓸모없는 이름 인 'SR_M_DLY_ADV_PRD_S'에서 'IDX_FDSHRCLAS_LIF_RTRN_STATS_X'FML로 바뀌 었습니다.

따라서 수십 년에 걸친 경험에서 단축 된 테이블 이름은 실질적인 이점을 제공하지 않으며 화면의 가비지를 의미있는 식별자로 변환하기 위해 항상 데이터 사전을 참조해야하기 때문에 개발 및 유지 관리 비용이 높아집니다. 논리적으로 명명 된 엔터티와 대조 할 수 있으며 직관적으로 명명 된 메모리이기 때문에 대부분 메모리에서 다시 생성 할 수 있습니다.

습관입니다 (Kevinsky에 동의합니다). 운영 체제 (예 : DOS, Windows)의 제한 (이름 길이, 복잡한 이름의 단어 사이의 공백, 다국어 등) 및 그러한 이름을 처리하지 않은 일부 소프트웨어에 대한 오래된 (아마도 존재할 수 있음) 문제에 대한 반응이었습니다. 경험이 풍부한 사람들은 "그렇게하고 (짧고 밑줄로 구분 된 이름을 사용) 모두 괜찮을 것"이라고 말했다.

앞에서 언급 한 이유 때문에 포스터에서 설명이 포함 된 이름을 사용하고 싶습니다.

그러나 또 다른 이점도 있습니다. 예를 들어, 설명이 포함 된 이름을 사용하면 중첩 이름을 사용할 수 있습니다. Employee라는 테이블이 있다고 가정하십시오. 다른 테이블과 관계가 있으면 EmployeeAddress라고 할 수 있습니다. 또는 EmployeeDepartment. 비밀스럽고 축약 된 이름을 사용하면 거의 불가능합니다.

각 열의 기본 정의가 얼마나 복잡한 지에 따라 다릅니다. 나는 사람들이 이런 종류의 매우 묘사적인 열 이름을 볼 때 메타 데이터 관리에 게으르다 고 생각하며 실제로는 불완전한 설명조차합니다. 왜 약어를 사용하는지 물어볼 수도 있습니다.