DBNull의 요점은 무엇입니까?

DBNull의 요점은 무엇입니까?

---

.NET에는 null객체 참조가 비어 있음을 나타 내기 위해 모든 곳에서 사용되는 참조가 있으며 DBNull, 데이터베이스 드라이버 (및 기타 일부)에서 표시하는 데 사용되는, 거의 동일한 것을 나타냅니다. 당연히 이것은 많은 혼란을 야기하고 변환 루틴을 쫓아 내야합니다.

그렇다면 원래 .NET 작성자가 이것을 만들기로 결정한 이유는 무엇입니까? 나에게는 말이되지 않습니다. 그들의 문서는 의미가 없습니다.

DBNull 클래스는 존재하지 않는 값을 나타냅니다. 예를 들어 데이터베이스에서 테이블 행의 열에는 데이터가 전혀 포함되지 않을 수 있습니다. 즉, 열은 단순히 값이없는 것이 아니라 전혀 존재하지 않는 것으로 간주됩니다. DBNull 개체는 존재하지 않는 열을 나타냅니다. 또한 COM interop은 DBNull 클래스를 사용하여 존재하지 않는 값을 나타내는 VT_NULL 변형과 지정되지 않은 값을 나타내는 VT_EMPTY 변형을 구분합니다.

"존재하지 않는 열"에 대한이 쓰레기는 무엇입니까? 열이 존재하지만 특정 행에 대한 값이 없습니다. 존재하지 않는 경우 특정 셀에 액세스하려는 경우 예외가 발생합니다 DBNull. VT_NULL과 를 구분해야 할 필요성을 이해할 수 VT_EMPTY있지만 COMEmpty대신 클래스를 만드는 것은 어떻습니까? 그것은 전체 .NET 프레임 워크에 훨씬 더 깔끔하게 맞을 것입니다.

내가 뭔가를 놓치고 있습니까? 누구든지 DBNull발명 된 이유 와 해결하는 데 도움이되는 문제를 밝힐 수 있습니까 ?

---

요점은 특정 상황에서 데이터베이스 값이 null과 .NET Null 사이에 차이가 있다는 것입니다.

예를 들면. ExecuteScalar (결과 집합에서 첫 번째 행의 첫 번째 열을 반환 함)를 사용하고 null을 반환하면 실행 된 SQL이 값을 반환하지 않았 음을 의미합니다. DBNull을 다시 얻으면 SQL에서 값이 반환되었고 NULL이라는 의미입니다. 차이를 구분할 수 있어야합니다.

---

나는 여기의 추세에 동의하지 않을 것입니다. 나는 기록 할 것이다 :

나는 DBNull유용한 목적에 부합 하는 것에 동의하지 않습니다 . 불필요한 혼란을 추가하는 동시에 사실상 가치를 제공하지 않습니다.

인수는 종종 null유효하지 않은 참조 DBNull이며 이는 널 오브젝트 패턴입니다. 둘 다 사실이 아닙니다 . 예를 들면 :

int? x = null;

이것은 "잘못된 참조"가 아닙니다. 그것은 인 null값. Indeed null는 의미하는 null바를 의미하며, 솔직히 나는 값을 가지고 작업하는 데 전혀 문제가 없습니다 (실제로 SQL에서도 올바르게 작업해야합니다 null. 여기서 변경 사항은 없습니다). 마찬가지로, "null 객체 패턴"은 실제로 OOP 용어로 객체로 취급하는 경우에만 의미가 있지만 "우리의 가치 또는"가 될 수있는 값이있는 DBNull경우이어야합니다 object. 따라서 할 수 없습니다. 유용한 일을하세요.

다음과 같은 나쁜 점이 너무 많습니다 DBNull.

• 또는 다른 값만 보유 할 수 object있으므로 로 작업해야 합니다.objectDBNull
• "값이나 될 수 사이에 진정한 차이가없는 DBNull대"값이나 될 수있다 "는 null"
• 1.1 (pre-nullable-types)에서 유래했다는 주장은 의미가 없습니다. 우리는 null1.1에서 완벽하게 잘 사용할 수 있습니다.
• 대부분의 API에는 "null입니까?" 예를 들어, DBDataReader.IsDBNull또는 DataRow.IsNull-API DBNull측면에서 실제로 존재하지 않아도 되는 메소드
• DBNullnull-coalescing 측면에서 실패합니다. value ?? defaultValue값이 다음과 같으면 작동하지 않습니다.DBNull
• DBNull.Value 상수가 아니기 때문에 선택적 매개 변수에 사용할 수 없습니다.
• 의 런타임 의미는 DBNull의 의미와 동일합니다 null. 특히, DBNull실제로 동일 DBNull- 그렇게 하지 않습니다 는 SQL의 의미를 표현 일을 할
• 과도하게 사용하기 때문에 종종 값 유형 값을 boxing하도록 강제합니다. object
• 당신이 테스트를 위해 필요한 경우 DBNull, 당신은뿐만 아니라 단지 테스트 수도null
• 매개 변수에 null값이 있으면 전송되지 않는다는 매우 어리석은 동작으로 명령 매개 변수와 같은 것에 큰 문제가 발생 합니다. 여기에 아이디어가 있습니다. 매개 변수를 전송하지 않으려면- 하지 마십시오. 매개 변수 컬렉션에 추가
• 내가없이 완벽하게 잘 작동 생각할 수있는 모든 ORM 어떤 필요 또는 사용 DBNullADO.NET 코드를 이야기 할 때, 추가 귀찮은 경우를 제외하고

그러한 값 의 존재 를 정당화하기 위해 내가 본 적이 있는 원격으로도 설득력있는 유일한 주장 은 새로운 행을 만들기 위해 값을 전달할 때입니다. a 는 "기본값 사용"을 의미하고, a 는 명시 적으로 null입니다. 솔직히이 API는이 경우에 대해 특정 처리를 할 수있었습니다. 예를 들어 가상 은 이유없이 방대한 양의 코드를 감염시키는 a 를 도입하는 것보다 훨씬 낫습니다 .DataTablenullDBNullDataRow.DefaultValueDBNull.Value

마찬가지로 ExecuteScalar시나리오는 ... 기껏해야 미약합니다. 스칼라 메서드를 실행하는 경우 결과가 예상 됩니다. 행이없는 시나리오에서는 반환 null이 너무 끔찍해 보이지 않습니다. "행 없음"과 "반환 된 하나의 단일 null"사이를 명확하게 구분해야하는 경우 독자 API가 있습니다.

이 배는 오래 전에 항해했으며, 그것을 고치기에는 너무 늦었습니다. 그러나! 모든 사람이 이것이 "명백한"일이라는 데 동의한다고 생각 하지 마십시오 . 많은 개발자들은 BCL에서이 이상한 주름의 가치를 보지 못합니다 .

이 모든 것이 두 가지에서 비롯된 것인지 실제로 궁금합니다.

• NothingVB에서 "null"과 관련된 단어 대신 단어를 사용해야합니다.
• 미국에 수있는 if(value is DBNull)구문은 "단지 SQL 같은 외모", 오히려 오 - 그래서 - 까다로운 이상if(value==null)

요약:

세 가지 옵션 ( null, DBNull또는 실제 값)을 갖는 것은 세 가지 다른 경우를 명확하게해야하는 실제 예제가있는 경우에만 유용합니다. 두 개의 서로 다른 "null"상태를 나타내야하는 경우를 아직 보지 못 했으므로 이미 존재하고 훨씬 더 나은 언어 및 런타임 지원을 DBNull제공 하므로 완전히 중복 null됩니다.

---

DbNull내용물이없는 상자를 나타냅니다. null상자가 없음을 나타냅니다.

---

누락 된 데이터에 대해 DBNull을 사용합니다. .NET 언어에서 Null은 개체 / 변수에 대한 포인터가 없음을 의미합니다.

DBNull 누락 데이터 : http://msdn.microsoft.com/en-us/library/system.dbnull.value.aspx

누락 된 데이터가 통계에 미치는 영향 :

http://en.wikipedia.org/wiki/Missing_values

---

CLR null과 DBNull 간에는 몇 가지 차이점이 있습니다. 첫째, 관계형 데이터베이스의 null은 "equals"의미가 다릅니다. null은 null과 같지 않습니다. CLR null IS는 null과 같습니다.

그러나 주된 이유는 매개 변수 기본값이 SQL 서버에서 작동하는 방식과 공급자의 구현과 관련이 있다고 생각합니다.

차이점을 확인하려면 기본값이있는 매개 변수를 사용하여 프로 시저를 작성하십시오.

CREATE PROC [Echo] @s varchar(MAX) = 'hello'
AS
    SELECT @s [Echo]

잘 구성된 DAL 코드는 명령 생성과 사용을 분리해야합니다 (예를 들어 저장 프로 시저를 여러 번 효율적으로 호출하기 위해 동일한 명령을 여러 번 사용할 수 있도록하기 위해). 위의 절차를 나타내는 SqlCommand를 반환하는 메서드를 작성합니다.

SqlCommand GetEchoProc()
{
    var cmd = new SqlCommand("Echo");
    cmd.Parameters.Add("@s", SqlDbType.VarChar);
    return cmd;
}

If you now invoke the command without setting the @s parameter, or set its value to (CLR) null, it will use the default value 'hello'. If on the other hand you set the parameter value to DBNull.Value, it will use that and echo DbNull.Value.

Since there's two different results using CLR null or database null as parameter value, you can't represent both cases with only one of them. If CLR null was to be the only one, it'd have to work the way DBNull.Value does today. One way to indicate to the provider "I want to use the default value" could then be to not declare the parameter at all (a parameter with a default value of course makes sense to describe as an "optional parameter"), but in a scenario where the command object is cached and reused this does lead to removing and re-adding the parameter.

I'm not sure if I think DBNull was a good idea or not, but a lot of people are unaware of the things I've mentioned here, so I figured it worth mentioning.

참고URL : https://stackoverflow.com/questions/4488727/what-is-the-point-of-dbnull