데이터베이스 열의 경우 자세한 이름을 사용 하시겠습니까?

Question

당신의 선호도는 어느 것입니까?

ID, 이름 및 카테고리에 대한 외래 키 참조가있는 일반 제품 표가 있다고 가정 해 보겠습니다. 같은 당신은 당신의 테이블 이름을 선호 :

CREATE TABLE Products 
(
    ProductID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryID), 
    ProductName varchar(200) NOT NULL 
) 

이 열에 대한 명시적인 이름을 사용하여 (예를 들어 제품 이름, 제품 ID)와 같은, 또는 무언가 :

CREATE TABLE Products 
(
    ID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryID int NOT NULL FOREIGN KEY REFERENCES Categories(ID), 
    Name varchar(200) NOT NULL 
) 

내가 '무엇부터 .NET 세계에서의 컨벤션은 분명합니다. 샘플은 첫 번째 예제를 사용하는 반면, 오픈 소스와 RoR 세계는 두 번째 샘플을 선호합니다. 개인적으로 내가 처음 쉽게 읽고 언뜻 이해하기 찾습니다 select p.ProductID, p.ProductName, c.CategoryName from Categories c inner join Products p on c.CategoryID = p.CategoryID은 더 많은 자연 나에게 select p.ID AS ProductID, p.Name AS ProductName, c.Name AS CategoryName from Categories c inner join Products p on c.ID = p.CategoryID

보다는 내 생각 보인다 나는 그것이 큰 문제가 아니지만, 당신은 어떻게 처리하는 경우에 대해 제공하는 기초적인 예를 제공 많은 데이터와 표가 있습니까? 비록 첫 번째 예제가 두 번째 것보다 더 좋을지 모르지만 (ID의 경우 <Table>ID이지만 이름은 Name일까요?) 두 가지 중 일부 조합을 살펴볼 가치가 있습니다. 분명히 이미 존재하는 프로젝트에 대해서는 기존의 규칙을 따라야하지만, 새로운 개발은 어떨까요?

무엇이 좋나요?

Answer 1

테이블 이름은 이미 컨텍스트를 제공합니다. 열 이름 앞에 접두어를 붙일 필요가 없습니다. 테이블을 조인 할 때 table.column 구문을 사용합니다.

Answer 2

내가 옵션 3의 팬입니다 :

CREATE TABLE Products 
(
    ProductId int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    CategoryId int NOT NULL FOREIGN KEY REFERENCES Categories(CategoryId), 
    Name varchar(200) NOT NULL 
) 

그래서 기본 키가 접두어로 테이블의 이름을 얻을 수있는 유일한 열이 - 이럴 그것은이 간 가입 할 때 쉽게 참조 할 수 있습니다 잘못된. 그런 다음 다시 병합 복제 상황에 대처해야 할 가능성이있는 경우 기본 키에 GUID를 사용하는 것을 좋아합니다.

Answer 3

한 가지 생각은 열 이름이 데이터베이스 전체에서 단일 도메인 공간. 예를 들어, 제품 이름은 회사 이름과 상당히 다른 것입니다. 하나는 다른 것보다 길 수도 있습니다. 그런 점에서 두 메소드를 구분하기 때문에 첫 번째 메소드를 사용해야합니다.

한편, Think Before Coding의 논리에 어느 정도 동의합니다. 나는 항상 table.column 구문을 사용하므로 문맥이 명확해야한다.

보다 자세한 열 이름을 사용하면 대개 예약어와의 충돌을 피할 수 있습니다.

또한 제품 테이블의 모든 열이 ProductXxxx 인 경우에도 매우 중복 될 수 있습니다.

다른 말로하면, 절대 선호도가 없지만 자세한 명명 규칙을 따르는 경향이 있습니다.

Answer 4

"ID"의 짧은 버전을 선호합니다. 테이블에 대한 레코드 식별자가 "ID"로 불리며 다른 테이블이 아닌 "자신의"테이블을 참조하게됩니다. (때때로 "자체"식별자가 필요하지 않습니다. 매핑과 같은 일부 테이블).

또 다른 결과는 쿼리를 작성할 때마다 정확한 열 이름을 생각하고 기억할 필요가 없다는 것입니다. 테이블이 레코드 식별자를 갖는 것이 의미가 있 자마자 "ID"로 참조 될 수 있음을 알고 있습니다.

사물을 단순화합니다.

Answer 5

대개 나는 각 테이블에 고유 한 접두사를 제공합니다. 따라서 귀하의 예는 다음과 같습니다.

CREATE TABLE Products 
(
    PROD_ID int NOT NULL IDENTITY(1,1) PRIMARY KEY, 
    PROD_CAT_ID int NOT NULL FOREIGN KEY REFERENCES Categories(CAT_ID), 
    PROD_NAME varchar(200) NOT NULL 
) 

이렇게하면 이름 충돌이 없으므로 열을 더 쉽게 결합하고 선택할 수 있습니다. 동일한 테이블을 두 번 이상 참조하지 않으면 테이블 이름 별칭 (대부분 가능)이 필요하지 않습니다.

그러나 요즘 저는 (2)가 더 좋을 수도 있습니다. 왜냐하면 코드를 작성할 때 (예 : C#) 내 이름 지정 규칙에 가깝기 때문입니다.

Answer 6

가능한 한 짧은 이름으로 붙어 있습니다. 모든 컬럼에 테이블의 이름 앞에 접두어를 붙이는 사람들은 나를 폭력적으로 만듭니다. PERSON.first_name이 아니라 PERSON.first_name. 우리는 그 사람을 알고 있습니다, 그 사람의 테이블에 ... 그 밖에 있을까요?

이 규칙을 위반하는 경우는 id 열에 대한 것입니다 (예 : PERSON.personID).

규칙은 아인슈타인에게 사과합니다. 필요에 따라 자세한 정보를 표시하지만 더 자세한 정보는 표시하지 않습니다.

Answer 7

난 당신이 조인 많이있을 때

Answer 8

ID는 몹시 혼란 등등 UID, GID, PID, 떨어 졌, 뚜껑을 선호합니다. foregin 키에있는 id의 이름과 일치하는 id의 이름을 추출하는 것을 선호합니다. 그렇게하면 항상 고객 ID가 열이있는 다른 테이블에서 고객 ID와 조인된다는 것을 알 수 있습니다.

절대 필드 이름으로 name을 사용하지 마십시오. 예약어이므로 피해야합니다. 예약 된 keyworsd는 데이터베이스에서 일부 방식으로 사용됩니다. 파일 이름을 사용하면 프로 액티비티가 좋지 않으므로 시작 부분에 올바른 설명 형식을 사용하는 것보다 많은 오류가 발생할 수 있습니다.

Answer 9

확인 또한 관련 질문 : I mentioned in my answer으로 Is prefixing each field name in a table with abbreviated table name a good practice?

; 테이블 이름 앞에 필드 이름 접두어를 붙이는 개념은 전체 데이터베이스의 각 필드가 고유해야 할 때 레거시 시스템의 이전 시간에서 왔습니다. 현대 시스템에서는 더 이상 필요하지 않으므로 더 이상 필요하지 않은 컨벤션 일뿐입니다. Think Before Coding에서 언급 한 바와 같이 "의 표 이름이 이미 컨텍스트를 제공합니다. 접두어 열 필요가 그것으로 이름을 없다"열 이름은 데이터베이스에서 고유하지 않으면 내가 생각

Answer 10

, 당신은 TABLENAME와 접두사해야한다. ProductId, ProductName과 같습니다. 다른 테이블의 열과 충돌하지 않는 열의 경우 접두사를 붙이지 마십시오.

Answer 11

옵션 2가 가장 좋습니다 (당연히 :) :)
저는 PHP 프로그래머로서 .NET이 아닙니다.

Answer 12

첫 번째 옵션이 불필요한 반복으로 보이기 때문에 두 번째 옵션을 선호합니다. 물론 저는 주로 Ruby on Rails 프로그래머이므로 DRY principle을 좋아합니다. :) 모든 것이 첫 번째, 명시 적 - 반복적 인 버전을 사용하기 때문에 C# 프로그래밍에 짜증나는 것을 발견했습니다.