열에 기본값을 두는 것의 이점은 무엇입니까?

Question

이 질문이 너무 광범위하면 사과드립니다. 저는 DBA이고 열 기본값이 좋지 않다고 생각하는 개발자와 협력하고 있으며 null을 허용하지 않도록 열을 설정하는 것으로 충분합니다.

개발자 관점에서 열 기본값의 이점을 찾고 있습니다. 의견을 주셔서 감사합니다.

Answer 1

열 기본값을 사용하면 코드 또는 응용 프로그램 논리에서 레코드를 만드는 번거 로움을 많이 제거 할 수 있습니다.

장점 # 1 : 사용자 정보가 2 열이고 tinyint/boolean 필드가 20 열인 테이블이있는 경우 개인 정보 설정이 있다고 가정하고이 테이블에 새 레코드를 만들면 쿼리의 모든 열을 지정해야하는 값 DEFAULT. 이 레코드가 기본적으로 갖기를 원하는 일반적인 설정이있을 수 있으며 값을 사용하여 설정할 수 있습니다. INSERT 레코드 일 때 두 개의 사용자 정보 필드 만 지정하면됩니다. 레코드가 멋진 개인 정보 보호 설정으로 생성됩니다. 그 후 개별적으로 플래그를 조정할 수 있습니다.

이점 # 2 : 앞으로의 호환성! 코드에 INSERT 개의 묶음이 있고 일부 열이 추가 된 경우 값을 지정하지 않으면 모두 돌아가서 모든 해당 값을 수정해야합니다 (가정 할 때 일반적이라고 가정 함). 그 NULL는 그것을 자르지 않을 것이다).종종 새로운 열에 대한 이전 코드를 업데이트 할 필요가 없습니다 (원래 코드는 새로운 열에 신경 쓰지 않으므로 일 것입니다). 시작해야하는 경우 @ $$에 큰 통증이 있습니다. 돌아가서 코드에있는 모든 새로운 열을 처리합니다.

Answer 2

기본값을 사용하면 테이블에 새 행을 삽입하는 것이 훨씬 쉬워집니다. 기본값이있는 모든 열을 명시 적으로 지정하지 않고 INSERT 문에 값을 제공 할 필요가 없습니다. 기본값 인 경우 "LastChangeOn"날짜 열에 대해서는 getdate()).

이 아닌 이유는 알 수 없습니다.은 실제로 유효하고 합당한 기본값이있는 경우 실제로 열에 기본값을 사용합니다. 나는 개발자가 왜 디폴트 값에 대한 혐오감을 갖고 있는지 보지 못한다. 초기 INSERT에서 항상 오버라이드 될 수있다.

마크

Answer 3

귀하의 요구 사항에 따라 다릅니다. 규칙에 최소값이 필요하고 NULL이 유효한 옵션으로 간주되지 않으면 기본값이 필요할 수 있습니다. 예를 들어 감사 필드가있는 경우 CREATED_DATE 열에 null 값을 지정하지 않을 것입니다. 그러나 MIDDLE_NAME 특성이있는 경우 모든 사람이 중간 이름을 갖고 있기 때문에 NULL을 허용하려고합니다. 다시 말하지만, 그것은 실제로 귀하의 요구 사항에 달려 있습니다.

Answer 4

기존 테이블에 열을 추가하고 해당 열을 Null 허용하지 않으려면 기본값을 제공해야합니다.

Answer 5

많은 개발자가 비즈니스 논리를 데이터베이스에 넣는 것을 좋아하지 않습니다. 개발자는 자신이 통제력을 상실하고 있다고 생각할 수 있습니다 (자신이 기본값을 null로 설정하는 루틴을 작성할 수 있습니다). 나는 그가이 일을 찬성/그의 일에서 벗어나는 것으로 보는지 확신 할 수 없다.

타사 응용 프로그램의 백엔드 인 데이터베이스를 처리하며 응용 프로그램에서 수행 할 수있는 작업이 제한되어 있습니다 (기본값 포함). 응용 프로그램이 모든 데이터 입력 패널에서 기본값을 갖도록 강제 할 수 없으므로 컨트롤이있는 데이터베이스의 필드에 기본값을 넣고 싶습니다. 코드에 액세스 할 수 없어 사용자가 업그레이드를 기다리는 것을 원하지 않습니다.

Answer 6

컬럼 기본값은 프로그래머가 게으르도록 허용합니다. 그것은 반드시 나쁜 것은 아닙니다.

Answer 7

개발자는 아주 좋은 지적입니다. 일반적으로 암시 적 행동에 의존하는 것이 아니라 가능하면 명시 적으로하는 것이 좋습니다.

나는 그/그녀가 옳을 수도 있다고 생각합니다. 컬럼에 기본값을두고 코드가 그것에 의존하는 경우, 기본값을 변경하면 추방하기 힘든 버그가 나중에 발생할 수 있습니다.

그러나 데이터 테이블 자체에 기본값을두면 코드를 다시 컴파일하지 않고 나중에 열의 기본값을 변경할 수 있습니다. 즉, 코드를 작성하는 사람이 절대적으로 필요한 경우를 제외하고는 기본값을 무시하지 않을 정도로 충분히 앞으로 생각했습니다.

Answer 8

버전 관리에 도움이됩니다. 예를 들어 오래된 코드 (INSERT 문)가 10 개의 열이있는 테이블을 필요로하고 이전 코드가 12가있는 새 테이블과 함께 작동해야한다면 새 열에 대한 기본값을 제공하거나 새 열을 Nullable로 만들어야합니다 .

또한 기본값의 선택은 열의 NULL에 대한 선택이기 때문에 또한 주어진 열에 대한 NULL의 의미에 대한 정확한 의미에 따라 달라집니다. 빈 토큰은 알려지지 않은, 알 수없는 것, 아직 변경되지 않은 것, 알 수없는 과거의 것, 알려지지 않은 미래의 것 등을 의미합니다. 이들은 약간 다른 토큰이며 NULL은 그 중 하나만 의미 할 수 있습니다.

Answer 9

DB의 기본값에 따라 방어적인 프로그래밍과 미래의 악몽을 보는 것에 완전히 부합한다고 생각합니다.

Answer 10

일반적으로 기본값은 호출되지 않습니다. 데이터에 의미가있는 기본값이 있으면 데이터베이스에 코드를 작성하십시오. 그러나 대부분의 데이터에는 기본값이 없습니다. 이름의 기본값은 무엇입니까? not null에 던져 코드가 값을 할당하게하십시오. 코드가 가짜 기본 이름 대신에 이름을 설정하지 못하면 오류가 발생하기 때문에 기본값을 포함하지 마십시오.

한 곳에서 간단한 "감사"구성표를 사용하는 것이 좋습니다. 모든 테이블에는 네 개의 열이 있습니다. InsertedAt, InsertedBy, UpdatedAt, UpdatedBy, not null 제약 조건이 있습니다. After 트리거를 사용하여 값을 설정했지만 SQL Server는 열에 값이 있는지 확인합니다. 제약 조건 위반이 발생하지 않았 으면 방아쇠로 돌아 가지 않았습니다. 그래서이 값들은 삽입을하는 코드에 의해 설정되지 않았기 때문에 기본값을 추가했습니다. 기본값은 1900 년 1 월 1 일 자정이며 존재하지 않는 사용자입니다. 트리거는 값이 기본값과 일치하는지 확인하고 누군가 삽입시 값을 설정하려고하면 오류를 던집니다. (또한 누군가가 감사 열을 업데이트하려고 시도하면 오류가 발생했습니다.)

Answer 11

상황에 따라 다릅니다. 기본값을 사용하면 사람들이 데이터를 올바르게 얻을 수있는 많은 경우가 있습니다. 데이터 입력 양식은 종종 패턴을 충족시킵니다. 데이터 입력 양식에서 앞으로 진행하기 전에 기본값을 유효성 검사를 위해 사용자에게 다시 표시 할 수 있습니다. 이것은 종종 기본값이 터무니없는 경우 사용자가 기본값을 대체 할 수있게합니다.

그러나 사용자 인터페이스와 프로그래머 인터페이스는 매우 다른 것들입니다. DB에 기본값을 제공하면 가비지 정보를 쉽게 입력 할 수 있습니다. 일단 DB에있는 쓰레기 정보를 제거하는 것은 노동 집약적입니다.

그래서 ...디자인 스펙에서 요구할 때만 기본값을 설정합니다. 이 경우 개발자의 의견은 설계 사양에 크게 영향을 주어야합니다.