나는 (일부 브렌트 Ozar 비디오를보고 있어요 예를 들어, 이와 같은를 ) 그는 함께 테이블 접두어하지 제안 ‘tbl’나 ‘TBL’.

인터넷에서 문서에 아무것도 추가하지 않고 "읽는 데 시간이 더 오래 걸린다"고 말하는 일부 블로그를 발견했습니다.

질문과 고려 사항

• 이게 진짜 문제 야? 첫 번째 dba 작업 이후에 테이블에 'tbl'접두어를 붙이기 때문에 (선임 DBA가 조직을 위해 그렇게 지시했습니다).
• 이것을 제거해야합니까? 나는 큰 테이블을 복사하고 'tbl'접두사를주지 않고 다른 테이블을 유지하면서 몇 가지 테스트를 수행했으며 성능 문제는 발견하지 못했습니다.

나는 한 번 테이블을 가지고 있었고 그것은 반짝이고 아름다웠다. 조직의 모든 금융 거래를 개최했습니다. 그런 다음 데이터를로드하기 시작했습니다.

이번 달에는 원하는 횟수만큼 값을 진술하고 다시 말할 수 있습니다. 한 달의 마지막 10 일 동안, 그들은 숫자를 다시 말하고-> ETL 처리를 실행합니다-> 보고서를 하루에 여러 번 검토합니다. 월이 완료되면 장부가 봉인되고 값을 수정할 수 없습니다.

금융 서비스 회사가 얼마나 많은 재무 데이터를 생성하는지는 놀랍습니다 ... 테스트 데이터 세트로 알지 못하는 것은 데이터의 양이 월말 절차를 유지할 수 없다는 것이 었습니다. 새 평가판 실행으로 교체하기 전에 "현재 월의 데이터"를 삭제하는 데 점점 오랜 시간이 걸렸습니다.

우리는 MonthlyAllocation 테이블에 의존하는 "무엇을 아는가"의 범주화되지 않은 목록을 깨뜨리지 않고 처리 속도를 높이기 위해 무언가를해야했습니다. 나는 마술사를 연기하고 식탁보를 그 밑에서 채찍질하기로 결정했습니다. 나는 구식으로 가서 Partitioned View를 사용했습니다 . 데이터에 이미 IsComplete 플래그가 있으므로 두 가지 테이블을 만들었습니다. 각 테이블에는 반대 제약 조건이 있습니다 : MonthlyAllocationComplete, MonthlyAllocationInComplete

그런 다음 원래 테이블과 동일한 이름을 가진 분할 된 뷰를 만들었습니다 : MonthlyAllocation. 데이터베이스의 물리적 변경에 대한 현명한 프로세스는 없었습니다. 보고 된 바가 없으며 직접 액세스 할 수있는 분석가 중 어느 누구도 그 "표"관련 문제를보고하지 않았습니다.

멋진 이야기는 끝났지 만 어디로 가는가?

그들이 tbl_MonthlyAllocation이라는 명명 규칙을 가지고 있다면 어떨까요? 이제 뭐? 조직의 모든 ETL, 모든 보고서, 임시 스프레드 시트 및 vw_MonthlyAllocation을 사용하도록 업데이트하는 데 많은 시간을 소비합니까? 물론 이러한 모든 변경 사항은 변경 보드를 거치며 항상 빠르고 쉬운 프로세스입니다.

당신은 상사가 물을 수도 있습니다. 모든 일에 대한 회사의 보상은 무엇입니까?

다른 옵션은이 뷰를 tbl_이라는 이름으로 남겨두고 코드를 테스트, 업데이트 및 배포하는 데 많은 시간을 소비하지 않습니다. 어떤 신입 사원들과 짧은 관심 범위를 가진 사람들에게 당신이 왜 객체의 이름과 일치하지 않는지 데이터베이스와 함께 일해야하는 재미있는 일화가되는 것

또는 중복 메타 데이터로 객체를 이중 인코딩하지 않습니다. 데이터베이스는 테이블, 뷰, 테이블 값 함수 등을 기꺼이 알려줍니다.

명명 규칙은 훌륭합니다. 자신을 모퉁이에 페인트하지 마십시오.

브렌트 여기 (당신이 질문에서 언급 한 사람).

테이블 이름 앞에 tbl을 추가하지 말라고하는 이유는 자녀의 이름 앞에 자식을 추가하지 않는 것과 같습니다. 당신은 그것들을 childJohn과 childJane이라고 부르지 않습니다. 그것은 가치를 부가하지 않을뿐만 아니라, 나중에 아이가 아닐 수도 있습니다-그리고 당신의 사물은 나중에보기가 될 수 있습니다.

이것은 매우 주관적인 주장이지만 여기에 내 취해야합니다 : tbl 접두사는 쓸모가 없습니다.

코드를보고있는 시나리오는 몇 개인 지, 어떤 것이 테이블인지 아니면 다른 것인지 알 수 없습니까?

Object Explorer에서 테이블 목록을 볼 때 찾고있는 테이블을 찾기 위해 더 많은 작업을 수행해야한다는 점을 제외하고 tbl은 어떤 가치를 더합니까?

어떤 사람들은 테이블이나 뷰를 다룰 때 코드에서 명확하게하기를 원한다고 말합니다. 왜? 그리고 이것이 중요하다면 왜 특별한 방식으로 뷰의 이름을 지정하지 않습니까? 대부분의 경우 테이블처럼 작동하므로 구별 할 가치가 거의 없습니다.

끔찍한 연습입니다.

tbl
tbl_
Table_
t_

... 생산에서 모두를 보았습니다.

현재 작업하고있는 제품 중 하나에는 표의 절반이 tbl_whatever있고 다른 표 에는 "정상"이라는 이름이 있습니다. 분명히 다른 표준으로 작업하는 개발자가 있습니다. 나쁜 습관 중 하나는 외래 키인 열 이름 앞에 fk, 테이블 이름, 열 이름을 접두어로 fk붙여서 끔찍한 열 이름을 지정하는 것 fktbl_AlarmsfkAlarmsID입니다. 그 명명 규칙은 전체 tbl_%진언 의 논리적 확장 일 뿐이며 그것이 얼마나 터무니 없는지 알 수 있습니다!

나는 매일 울고있는 다른 데이터베이스에 대해 거의 잊었다. dtPaymentDate이름에 실제로 dt접두사가 필요했기 때문에 열 이름 앞에 데이터 유형 접두어가 있습니다 ...

미리 준비하지 말고 다른 사람을 수정하십시오. 사전 고급 사전 준비 사전 준비 프 로젝트와 함께 adjTable nouName을 사용하십시오. proI auxHave advEven verveded gerProm Preprein aAdNormalNuWriting을 사용합니다.

comaddv 효과적인 효과는 무엇입니까? NUPeople auxCan verNuWriting adjBetter를 이해하십시오!

이와 같은 접두사를 사용하는 것을 헝가리 표기법이라고 합니다. 전제는 간단합니다. 이름이 어떻게 지정되어 있는지 확인할 수 있습니다. 이것은 특히 언어가 부족하거나 언어 기능이 부족하여 개발자가 수십 페이지에 걸친 단일 함수를 작성할 때 프로그래밍 언어에서 일반적입니다. 개발자가 데이터 유형을 똑바로 유지할 수 있도록 도와주는 니모닉 지원입니다.

일반적으로 말해서,이 스타일 이름은 실제로 오래된 코드 나, 배우거나 (이 습관을 알게 된) 개발자가 기억할 수있는 한 오랫동안 사용했을 가능성이 높습니다. 필자의 경험에 따르면, 헝가리어 표기법이 프로그래밍 과정이나 튜토리얼에서 소개되지 않은 경험이 부족한 개발자들과 함께 자발적으로 나타나는 것은 드물다. i 또는 x 또는 acct 와 같은 변수 이름을 사용할 가능성이 높습니다 .

구석에 자신을 그리는 것 외에도 이것은 실제로 필러입니다. SQL 구문은 개발자가 필드, 레코드 또는 데이터 세트 (테이블, 뷰 등일 수 있음)에 대해 이야기하고 있는지 항상 알아야하는 정도로 정확합니다. 훌륭한 교육 보조 도구가 될 수 있지만이 구문은 일반적으로 프로덕션 데이터베이스에 존재하지 않아야합니다. 가독성을 떨어 뜨리고 특히 tbl vs. table vs. tab 등과 같은 여러 가지 대체 명명 테마가 나타나는 경우 원하는 테이블을 찾기가 더 어려워집니다 .

데이터베이스는 정말 상관하지 않습니다 무엇을 당신이 그들은 단지 그들의 인간 운영자 또는 스크립트에 의해 특정 순서로 배열 된 데이터의 바이트있는 등 사용자의 테이블, 필드를 호출합니다. 그러나이 데이터를 유지해야하는 사람은 "사용자", "주문"및 "계정"과 같은 의미있는 이름을 인식하게됩니다. "show table like 'a %'"와 같은 SQL 쿼리를 사용하는 경우에도 더 실용적입니다. 접두사와 접미사를 사용하면 불필요하게 사소한 유지 관리가 복잡해질 수 있습니다.

내가 좋아하는 몇 가지 블로그 게시물 읽은 이 나 이 (꽤있다) 내가 처음으로 SQL 서버 인스턴스를 상속 접두사 곳, 내가 덜 자세한 정보 접근과 단수 명명 규칙과 새로운 개발을 시작하고 싶었 많은 개체를 발견 한 후 ( 내가 ( 그리고 아마도 다른 개발자들도 Object Relational Mapping) 작업을 훨씬 쉽게 할 수있다 .

가장 널리 사용되는 접두사 중 하나였다 Tbl거나 tbl, 그러나 나는했다 TBL및 tbl_심지어*TableName*_Tbl

Visual Studio에서 쿼리하고 작업하려고 할 때 이것은 지옥 일뿐입니다. 접두사 전체 테이블 세트를 갖는 것은 중요하지 tbl않지만 적어도 전체 데이터베이스에 대해 그런 식으로 유지하십시오.

결국 나는 개인적 선호의 문제라고 말하지만 일관성과 관련이 있으며 그 길을 따라 가면 적어도 많은 사람들이 행복하게 발전 할 것입니다.

... 반면, 다른 접근법을 취하고 접두사가 아닌 단일 이름 테이블을 사용하면 미래에 개발자를 행복하게 만들고 행복보다 더 중요한 것은 무엇입니까?

예, 개체 유형을 나타내는 접두사를 추가하는 것은 문제가되고 불필요 합니다. 때문에,

1. 때때로 사물은 인생을 무언가로 시작하지만 결국 다른 무언가가 됩니다. (예를 들어 테이블 tblXxx로 분할되었다 tblXxxY및 tblXxxZ새로운 두 테이블을 조인 볼 수있는 몇 가지 이유로 교체. 이제라는 전망이 tblXxx).
2. tbl편집기에 입력하면 자동 완성 기능이 45 초 동안 정지 된 다음 4000 개의 항목 목록이 표시됩니다.

그러나...

나는 악마의 옹호자 역할을하고 다른 사람들이 분명하게 조언 한 것을 말할 것입니다. 이 몇 가지 희귀 접미사 / 접두사가 도움이 될 수있는 경우, 그리고 여기에 내가 일하는 조직의 예입니다.

비즈니스 로직이 Oracle PL / SQL로 작성된 엔터티 기반 ERP 시스템이 있습니다. 거의 20 년이되었지만 매우 안정적인 시스템입니다 (이것은 레거시 시스템이 아닙니다. 우리는 지속적으로 개발하고 있습니다).

시스템은 엔터티 기반이며 각 엔터티는 테이블, 여러 뷰, 여러 PL / SQL 패키지 및 기타 다른 데이터베이스 개체를 연결합니다.

이제 동일한 엔터티에 속한 개체의 이름은 동일하지만 목적과 유형을 구별 할 수 있기를 원합니다. 따라서 이름이 CustomerOrder이고 두 개의 엔터티가 CustomerInvoice있으면 다음과 같은 개체가 있습니다.

1. 데이터를 저장하는 테이블 [ TAB접미사] :
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB.
2. 클라이언트가 사용하는보기 [접미사 없음] :
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE.
3. 기본 작업을위한 인터페이스 (PL / SQL 패키지) [ API접미사] :
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API.
4. 보고서 생성기; (PL / SQL 패키지) [ RPI접미사] :
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI.
5. 기본 키 색인 [ PK접미사] :
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK.
6. 보조 인덱스 [ IX접미사] :
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX(여기서 XXX색인 사용법을 설명합니다).
7. ... 등등.

이것은 실제로 Apps Hungarian 의 한 형태입니다 (같은 유형 의 객체는 목적에 따라 다른 접미사를 가질 수 있습니다). 그러나 접두사 대신 접미사가 있습니다. 이 시스템이 어떻게 읽기 쉬운 지 충분히 말할 수 없습니다. IntelliSense는 실제로 TBL4000 개의 결과 를 입력 하고 얻는 대신 Customer이름이 지정된 엔터티에 속하는 모든 개체를 입력 하고 가져올 수 있기 때문에 실제로 작동합니다 Customer*.

그래서, 여기에 내가 메타 데이터 방법을 보여 한 수 유용합니다. 목적은 단일 이름으로 식별 가능한 관련 데이터베이스 오브젝트 세트를 갖지만 목적에 따라 구별하는 것 입니다.

데는 말했다 당신이 이런 종류의 시스템이없는 경우, 접 두부 또는 접미 중 하나의 아무 소용이없는 타입 객체의가 .

우리는 같은 접미사를 사용하지 않은 것을 참고 _table, _package또는 _view(IE의 유형 객체의). 예를 들어 (3)과 (4)는 모두 PL / SQL 패키지이지만 다른 접미사를 사용합니다. (5)와 (6) 모두 동일하며 인덱스입니다. 따라서 접미사는 유형이 아니라 목적을 기반으로 합니다 .

tl; dr 중복 정보를 추가하여인지 오버 헤드를 유발하므로 제거해야합니다.

상황 은 특히 ​​컴퓨터 시스템에서 훌륭한 것입니다. 상황에 따라 호출 된 users것이 테이블, 뷰, 저장 프로 시저 또는 완전히 다른 것인지 알 수 없었습니다. 레거시 (또는 잘못 작성된) 시스템 및 언어는 종종 코드를 읽는 동안 컨텍스트를 해결하기 어렵게 만듭니다. 예를 들어, Bash에서는 최소한 함수의 내용을 읽지 function users않고 는 무엇을 할 수 있는지 알 수 없습니다 . Java에서는 Map<Uid,UserDetails> users()매우 투명하며 세부 사항을 쉽게 파헤칠 수 있습니다.

SQL 테이블에이 인수를 복용 할 때 의 소비자 것이 유용 할 것이다 users는 테이블 또는 뷰인지 알아? 즉, A는 tbl접두사가 모르는 소비자 무언가의 말하려고 하고 알 필요가 있습니까?아마도 대다수의 소비자가 이에 대해 DML 및 DQL 쿼리를 작성하기를 바랍니다. 그것들은 또 다른 데이터 소스 일 뿐이며, 뷰인지 테이블인지는 파티션, HDD 또는 SSD에 저장되어 있는지 또는 다른 기술적 세부 사항과 관련이 있어야합니다. 물론 DBA는 드문 DDL / DCL 쿼리를 실행하려면 이러한 세부 정보를 알아야하지만 스키마를 탐색하고 모든 기술적 세부 정보를 얻는 방법을 실제로 알고있는 소수를 위해 네임 스페이스를 오염시키는 것은 비생산적인 것 같습니다.

관계형 데이터베이스 관리 시스템의 기능 중 하나는 물리적 저장소에서 클라이언트로 정보를 논리적으로 표시하는 것입니다. 전자는 행 집합의 열입니다. 후자는 스토리지 볼륨의 파일입니다. 하나를 다른 것으로 매핑하는 것이 DBMS의 임무입니다. 정보 요구를 지원하는 하드웨어는 DBA 또는 sysadmin에만 관심이 있습니다. 소비자는 실제로 이러한 우려를 인식해서는 안됩니다.

클라이언트는 행 집합 구성 방법에 대해 걱정하지 않아도됩니다. 이 점에서 기본 테이블, 뷰 또는 함수는 모두 동일합니다. 각각은 단순히 클라이언트가 소비하는 일련의 행과 열을 생성합니다. 간단한 스칼라조차도 1 행 1 열 테이블로 간주 될 수 있습니다. 행 / 열 모델은 클라이언트와 서버 간의 계약입니다.

아티팩트 이름에 구현 유형을 접두사로두면 이러한 우려가 분리됩니다. 클라이언트는 이제 서버의 내부를 인식하고 의존합니다. 서버 코딩을 변경하면 클라이언트 재 작업이 필요할 수 있습니다.

여기에 나는 이것이 귀중한 명명 규칙이 아니라는 것을 알려주는 많은 답변이 있습니다. 다른 답변에 확신이없는 사람들을 위해 다른 답변이 무엇을 말하는지 보여 드리겠습니다.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

위의 진술에서 나는 이름이 지정된 것에서 세 개의 열을 선택하고 dbo.foo있습니다. 접두사에 대한 주요 불만 중 하나는 dbo.foo테이블 또는 뷰 인지 알 수 없다는 것 입니다. 물론 그것은 추상화로서의 견해의 강점 중 하나입니다. 그들은 우리가이 객체 앞에 접두사를 붙여야한다고 말합니다 dbo.tblFoo. 이제 그들은 위의 쿼리에서 객체가 테이블 일 수 있음을 알 수 있습니다. 그러나 우리가 그 목표와 동등한 기능을 쓰면 다음과 같습니다.

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

나는 그것이 접두사가 효과적으로 주장하고 있지만 주석이 유용하지 않다고 생각합니다. 이 메타 데이터 주석이 쓸모없는 노이즈를 강조하기 위해 더 복잡한 쿼리를 고려하십시오.

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

추가 의견은 해당 쿼리에 대해 추론하기가 더 쉬워 지거나 추가 노이즈를 추가합니까? 내 의견으로는 그들은 추가 노이즈를 추가하고 제로 값을 추가합니다. 이것이 바로 접두사들이 말하려는 것입니다. 또한 데이터 모델을 수정해야하는 경우 주석 업데이트 비용이 접두사 테이블의 이름을 업데이트하는 것보다 훨씬 낮기 때문에 접두사를 사용하는 것이 실제로 해당 주석보다 더 나쁩니다. 이러한 접두사는 비용이 많이 들고 중요한 정보를 제공하지 않으므로 피해야합니다.

일부 사람들이 인용하는 접두사의 또 다른 장점은 개발 환경에서 일종의 그룹화 또는 순서를 부여 할 수 있다는 것입니다. 우리는 코드를 편집하는 데 많은 시간을 소비하기 때문에 일부 사람들에게는 매혹적인 논쟁이 될 수 있습니다. 그러나 내 경험에 따르면 현대 개발 환경은 쓸모없는 메타 데이터로 코드를 버리지 않고 유연성을 제한하지 않는 동등하거나 우수한 옵션을 제공합니다.

이것은 여러 번 다루어졌지만 아마도 미국 SQL 및 관계형 데이터베이스 전문가 Joe Celko가 가장 유명 할 것입니다 . 나는 개인적으로 온라인 그의 호언 장담 하나의 수신 끝에 봤는데 (영광 느낌), 그는 "tibbling", 또는 좀 더 정확하게 "로 설명이 접두사에 대해 이야기 skeuomorphism ".

일반적인 개념은 이러한 접두어는 오래 전부터 (실제로 객체 이름에 대한 8 바이트 제한과 같은 이름 지정 제한으로 인해) 코딩 방식이며, 유용한 이유없이 프로그래머 세대에게 전달 된 것입니다. "완료되었습니다."

회사, 블로거 및 프로그래머는 자체 코딩 스타일로 정보를 전달하며 일부 스타일은 다른 스타일보다 조금 더 "프랑켄슈타인"일 수 있습니다. 회사는 "집 스타일"을 가질 수 있으며 프로그래머는이 연습을 배워야합니다.

원래 사용 된 이유가 더 이상 사용되지 않더라도 시간이 지남에 따라 상황이 달라집니다. "Tibbling"은 관계형 데이터베이스 관리에서 가장 잘 알려진 예 중 하나입니다.

반올림 : 값을 추가하지 않고 각 테이블 이름에 정확히 4 바이트의 저장 공간을 추가합니다. 최신 SQL Server 시스템에는 아무 것도 제공하지 않지만 더 나은 느낌이 들었다면 계속 사용하십시오.

내 제안은 당신이 이것을 즉시 중지하는 것입니다. 이렇게해도 불편한 경우 "_tbl"을 테이블 이름 끝에 추가 하십시오. 물론 이미 언급 한 이유로 그렇게 할 필요도 없습니다. 원래 당신에게 그렇게하라는 사람은 당신에게 나쁜 조언을하였습니다. "이것은 우리 조직의 잘못 설정된 시스템의 관점에서 의미가 있습니다"라는 조언이 나빴을지 모르지만,이 경우 문제를 해결하는 것이 그의 일이었습니다. 여전히 나쁜 충고.

“테이블 앞에 tbl을 붙이지 마십시오”가 실제로 문제가됩니까?

시스템에 관해? 아니요. 다른 사람들에 관해? 아마도. 로타 증오를 생성 할 수 있습니다.

나는 개인적으로 테이블에 접두사를 붙이지 않고 뷰, 저장 프로 시저, 함수 등과 같은 다른 객체에 대해서도 접두사를 붙입니다.

나는 그 일을 그만두라고 말해야 할 것입니다. 과거에는 이런 일이 있었지만, 계속 그렇게함으로써 환경에 온 새로운 사람들이 지역 대회라고 생각하고 계속할 것을 권장합니다. 하지만 그들은 계속하지 않고 약간 다르게 할 것입니다.

특정 항목에 대한 DB를 트롤링 할 때 객체 탐색기를 열고 스크롤 할 것이라고 생각하는 유일한 사람은 아닙니다. 알파벳 알파벳입니다. 접두사가 물을 흐릿하게하기 시작할 때까지, 나는 tblname, tbl_name, tbname, t_name 및 다른 수천 가지 변형을 가지고 있으며, 당신이 알고있는 테이블을 이미 찾기가 어렵습니다.

마찬가지로 모든 vw_ 또는 sp_ 접두사를 입력하면 누군가가 와서 SPname, spname, s_p_name을 얻게됩니다. 접두사를 모두 제거하면 소프트웨어는 항목이 무엇인지 알고 있으며 실제로 알아야 할 경우 접미사를 대신 사용하십시오. NameOfMyView_v, NameOfMyProc_sp. 시각적으로 훨씬 쉽게 검색

그러나 오랫동안 저장된 proc을 통해 트롤링하고 proc 또는 테이블이 무엇인지 쉽게 알 수 없다면 어떻게해야합니까? 어쨌든 이것들은 별칭이 될 것이며, 접미사가 그렇지 않더라도 구조에 올 수 있습니다.

당신이하는 일을 바꾸는 것을 두려워하지 마십시오. 만약 당신이 이미 명명 규칙에 맞서고있는 환경으로 들어가더라도 자신의 것을 구현하는 것을 두려워하지 말고 더 나은 것을 위해 변화를 시작하십시오. 기존의 혼돈을 일치시킴으로써 혼동을 줄이려는 기회는 없으며 더 나아가

접두사 'tbl'을 사용하는 이점을 생각해야한다면 현재 SSMS에서 intellisense를 사용하여 입력 할 수 있다는 것입니다.

select * from tbl

그런 다음 필요한 테이블 이름을 찾으십시오 (정확한 테이블 이름에 대해 모른다고 가정). 이것은 한 단계 작업입니다. 물론, 우리는 항상 추가 단계를 통해 테이블 ​​이름을 찾을 수 있지만 'tbl'접두사를 사용하면 이것이 1 단계 작업이므로 항상 접두사 ( 'tbl'은 아님)를 선호합니다. 내 숙제 프로젝트.

편집 : (여기서 많은 투표를 한 후에도 여전히 SQL Server의 특정 범주의 객체에 특정 접두사를 제공하는 틈새 이점을 지적하는 것이 가치 있다고 생각합니다). 스토어드 프로 시저 / 함수 / 뷰에 접두어가 있다고 불평하는 사람은 없지만 테이블에 대한 주장은 항상 있습니다. (나에게 현실 세계에서는 테이블에 접두사를 부여할지 여부를 덜 신경 쓸 수 없습니다).

나는 SQL Server 2005 일에 테이블 이름이 접두어가있는 저장 프로 시저 / 뷰에 어떤 테이블이 사용되는지 찾아야한다는 요구 사항이 있었으며 정규 표현식 / C #에서는 그렇게 쉬운 일이었습니다. (예, 다른 방법이 있다는 것을 알고 있습니다.

저의 커리어는 많은 "모범 사례"논문 / 기사를 읽음으로써 성장하지만, 다른 시나리오에서 거의 모든 "모범 사례"에 대해 충분한 예외를 보았습니다. 따라서, 나는 항상 나 자신과 동료 DBA에게 말하고, 비즈니스 요구 사항에 따라 판단하고, "모범 사례"는 확실한 위치를 차지하지만, 우리 환경의 상황에서만 고려 될 수 있습니다.

dbo.Uservs를 고려하십시오 dbo.tUser. 이제이 테이블이 사용되는 코드의 모든 위치를 찾고 싶다고 상상해보십시오. 어떤 버전이 이것을 더 쉽게 (또는 가능하게합니까?) "user"라는 단어는 변수 이름, 주석 등으로 ​​많은 오 탐지 가능성이 높습니다.

그것은 다른 답변에서 보지 못했지만 개발자 겸 DBA이기 때문에 다른 사람들은 레거시 코드에서 작업하지 않아도 될 수 있습니다. 쿼리는 스키마와 같은 것들에 대한 참조를 완전히 규정합니다. (모든 완전한하더라도, 당신은 찾을 필요가 dbo.User및 [dbo].[User]및 dbo.[User]등등과). 또는 "종속성 정보"가 오래되고 부정확 한 데이터베이스 버전 (예 : 이전 버전의 MS-SQL)

그래서 내가 작업 한 일부 프로젝트에서는 그와 같이 혼합 되어 더 선택적 검색어로 만들기 위해 t또는 v접두사 (tbl_는 어리 석음)를 지시했습니다.

이후의 프로젝트에서는 SQL Server 데이터 도구 (hello, 모든 참조 찾기) 및 ORM 계층을 통한 데이터베이스 액세스와 같은 기능을 통해 테이블의 모든 사용법을 찾는 것이 사소한 것이기 때문에 유틸리티가 없습니다.

각면에는 장점과 단점이 있습니다. 따라야 할 규칙을 결정하는 것은 팀이나 회사의 책임에 달려 있습니다.

우리는 하나의 tbl협약을 사용합니다 . 우리가 할 수있는 것과하지 말아야 할 것을 스크립트로 알고 있기 때문입니다. 우리는 마음 속으로 스키마를 모르는 프로젝트와 사람들을 다양하게 변화 시켰습니다. 테이블에는 논리적 이름이 있으므로 스크립트를 작성하는 동안 쉽게 길을 찾을 수 있습니다. 그렇게하는 동안 테이블을 찾으면 IntelliSense를 통해 테이블이라는 것을 즉시 알 수 있습니다. 접두사를 추가해도 많은 컨텍스트가 추가되지는 않는다고 주장 할 수 있습니다. 그러나 제거하면 컨텍스트가 없음을 의미합니다.

접두사를 사용하지 않는 유일한 장점은 호환성입니다. 그러나 이것이 잠재적으로 위험한 상황이라고 주장합니다. 물론 스크립트와 쿼리가 중단되지는 않지만 그 사실에 너무 의존하기 시작하지만 일부 항목은보기와 함께 작동하지 않거나 잘못 권고됩니다.

결국 팀이 선호하는 것과 코드 / 스크립트를 작성하는 방법으로 요약됩니다.

테이블 이름 앞에 "tbl"을 붙여야하는 이유가있었습니다. 데이터베이스 객체 목록을보고 있다면이 쿼리를 실행할 수 있습니다.

select * from sysobjects

테이블 만 가져 오려면 다음을 수행하십시오.

select * from sysobjects where type = 'U'

누가 그것을 기억할 수 있습니까? 테이블 이름이 모두 "tbl"로 시작하는 경우이 쿼리를 사용하면 유형 열의 값을 기억할 필요가 없습니다.

select * from sysobjects where name like 'tbl%'

SQL Server 2014에 태그를 지정 했으므로 SQL Server 2005부터는 적용되지 않습니다. 대신 다음을 수행 할 수 있습니다.

select * from sys.tables

테이블 이름 앞에 다른 이유를 생각할 수 없습니다.