많은 데이터베이스에서 성을 Null로 사용하면 어떻게 문제가 발생합니까?

71

BBC 에서 기사 를 읽었습니다 . 그들이 말한 예 중 하나는 성이 'Null'인 사람들이 일부 웹 사이트에 세부 정보를 입력하는 데 문제가 있다는 것입니다.

그들이 직면 한 오류에 대한 설명은 없습니다.

그러나 내가 아는 한 문자열 'Null'이며 실제 Null 값은 완전히 다릅니다 (데이터베이스 관점에서).

이것이 왜 데이터베이스에서 문제를 일으키는가?

database null

— 질식
소스

2

이 글은 프로그래머가 이름에 대해 가정하는 것에 대한 다소 유명한 블로그 기사입니다. BBC 기사에 인용 된 사람들 중 한 사람이 작성했습니다. kalzumeus.com/2010/06/17/…

— Jörg W Mittag

12

관련 xkcd

— David Grinberg

2

또한보십시오 : stackoverflow.com/questions/4456438/…

— Foon

4

TV 에서이 남자 를 처음봤을 때 데이터베이스 버그라고 생각했습니다. 그런 다음 그것이 실제로 그의 이름이라는 것을 알았습니다.

— Nate Eldredge

3

@JarrodRoberson "Jennifer Null"이 직면 한 문제에 대한 설명과 OP가 게시 한 링크에서 유사한 이름을 가진 "전체 전제는 거짓"이라고 어떻게 말할 수 있습니까? 실제 최종 사용자가 직면 한 실제 문제입니다.

— Steven Burnap

102

데이터베이스 문제를 일으키지 않습니다. 데이터베이스를 이해하지 못하는 개발자가 작성한 응용 프로그램에서 문제가 발생합니다. 문제의 근원은 많은 데이터베이스 관련 소프트웨어가 NULL 레코드를 문자열로 표시한다는 것 NULL입니다. 응용 프로그램이 NULL 레코드의 문자열 형식을 사용하는 경우 (대 / 소문자를 구분하지 않는 비교 작업 사용) 이러한 응용 프로그램은 모든 "null"문자열을 NULL로 간주 합니다. 결과적으로 Null이라는 이름은 해당 응용 프로그램에서 존재하지 않는 것으로 간주됩니다.

해결책은 NOT NULL데이터베이스에서와 같이 널이 아닌 열을 선언 하고 문자열 조작을 데이터베이스 레코드에 적용하지 않는 것입니다. 대부분의 언어에는 문자열 수준의 인터페이스가 필요없는 우수한 데이터베이스 API가 있습니다. SQL 인젝션과 같은 다른 실수를 줄이기 때문에 항상 선호해야합니다.

— 아몬
소스

30

그러나이 경우 해당 기사를 읽는 경우 성 필드를 만들면 NOT NULL다른 사람들에게 전체 문제가 발생할 수 있습니다. "일부 개인은 이름과 성이 아닌 단일 이름 만 갖습니다."

— MikeTheLiar

41

@Darkhogg 많은 사람들이 이것에 대해 나에게 동의하지 않지만 이름은 전자 메일 주소와 같다고 생각합니다. 유효성을 확인하지 말고 사용자에게 단일 텍스트 상자를 제공하고 원하는 것을 입력하십시오. 이것은 내가 정말로 필요하다면 정확한 방법으로 당신에게서 얻을 것이라는 정보입니다 .

— MikeTheLiar

8

@ mikeTheLiar 나는 이것의 이름을 모르지만 데이터에 지나치게 제한적인 규칙을 만드는 데 따른 모든 종류의 오류가 있습니다. 종종 응용 프로그램 및 데이터베이스에서 우편 번호와 전화 번호가 숫자로 정의되어 표시됩니다. 그것들은 수학 연산을 수행하는 것이 의미가 없기 때문에 실제로 숫자가 아닙니다. 따라서 누군가 캐나다 주소를 입력하려고하면 문제가 발생합니다.

— JimmyJames

19

@JimmyJames 네, 우편 번호는 숫자로 저장되며 갑자기 여기에 사는 사람 은 기본 8 우편 번호가 있습니다. "만약 당신이 그것으로 수학을하지 않으면, 그것은 전체 중지 문자열입니다."

— MikeTheLiar

8

트윗 담아 가기 이름을 단일 문자열로 취급 할 때의 문제 (일반적으로 동의합니다)는 성을 기준으로 알파벳순으로 정렬해야하는 경우입니다.

— TRiG

13

특정 질문에 대답하기 위해 웹 양식과 데이터베이스 사이의 이벤트 체인을 따라 여러 단계가 있습니다. 성 Null이 NULL값 으로 잘못 해석 되면 시스템은 완벽하게 유효한 이름을 유효하지 않은 것으로 거부 할 수 있습니다. 이것은 amon에서 설명한 대로 데이터베이스 계층에서 발생할 수 있습니다 . 우연히 이것이 이것이 특정 문제라면 데이터베이스는 아마도 Bobby Tables 공격 이라는 SQL 인젝션에 열려있을 것입니다 . 체인에서 문제를 일으킬 수있는 또 다른 단계 는 직렬화 프로세스 입니다.

전체 기사는 더 큰 문제에 관한 것이 었습니다. 세상은 우리의 가정에 항상 부합하지 않는 큰 지저분한 곳입니다. 이것은 응용 프로그램을 국제화하려고 할 때 특히 분명합니다. 하루 가 끝나면 애플리케이션이 데이터를 올바르게 처리하고 인코딩하도록해야합니다 . 점점 더 복잡한 엣지 케이스를 지원하기 위해 얼마나 많은 리소스를 사용할 것인지 결정하는 것은 비즈니스에 달려 있습니다. 포괄적 인 지원을 완벽하게 지원하지만 "공식적으로 Prince로 알려진 아티스트"가 데이터베이스에서 자신의 이름을 나타 내기 위해 유니 코드 문자를 사용해야한다고 결정하는 경우 이해합니다.

— 에릭
소스

SQL 삽입으로 이어질 수있는 안전하지 않은 문자열 보간으로 인해 이러한 현상이 발생한다고 상상하기 어렵습니다. SQL 쿼리에서 사용자 입력을 인용하는 것을 잊어 버린 경우 (예 :로 INSERT INTO users (first, last) VALUES($first, $last)평가 INSERT INTO users (first, last) VALUES(Jennifer, Null)) 이름 이 유효 하지 않은 모든 SQL 키워드 또는 열 이름은 오류를 발생 시키며 레코드도 삽입하지 않습니다. 원인은 더 복잡해야합니다.

— Andrew Medico

네 짚맨 예에서 @AndrewMedico는 그렇습니다.하지만 잘못하는 많은 방법이 있습니다. <strike> stupidity <\ strike> 무지의 힘을 과소 평가하지 마십시오. 결론은 문제의 코드를 검토 할 수 없기 때문에 실제 문제가 무엇인지 전혀 모른다는 것입니다.

— Erik

7

데이터베이스에 입력되기 전에 DOM 요소, 전달 된 JavaScript 변수, 유효성 검사 및 조작, JSON 값, 사용중인 백엔드 JSON 라이브러리의 변수, 전달 된 변수, 백엔드 프로그래밍 언어, DAO의 요소, SQL 문자열의 일부로 유효성을 검사하고 조작합니다. 그런 다음 값을 되 찾으려면 모두 반대로하십시오. 프로그래머가 실수를 저지르는 곳은 많으며, 정적 타이핑의 이점이없는 경우가 많습니다.

— 칼 빌레펠트
소스

2

프로그래밍 문제 일 가능성이 높습니다. NULL이 전달되는 방법에 대한이 답변을 보면 "Mr. Null"인 경우 원치 않는 동작이 발생할 수 있습니다.

https://stackoverflow.com/questions/4620391/mysql-and-php-insert-null-rather-than-empty-string

일부 데이터 요소가 NULL로 전달 된 경우 데이터는 데이터베이스에서 데이터베이스 널로 보간됩니다.

"NULL"! = 데이터베이스 널

일부 사용 사례 및 관련 동작 ...

데이터베이스에서 성이 null이 아닌 것으로 표시되었다고 가정 해 봅시다. 이제 데이터가 삽입되면 NULL로 해석되어 삽입에 실패합니다.

또 다른 경우는 데이터베이스에서 성이 널 입력 가능하다고 가정합니다. Mr. NULL이 삽입되고 "NULL"과 동일하지 않은 DBNull.Value로 변환됩니다. 삽입 후에는 Mr. Null을 찾을 수 없습니다. 그의 성은 "NULL"이 아니라 실제로 데이터베이스 널값이기 때문입니다.

따라서 두 가지 문제가 있습니다. @Amon이 지적했듯이 데이터베이스 자체에는 null과 관련된 문제가 없지만 공급 업체마다 차이가 있으므로 각 RDMS 인스턴스에서 null이 처리되는 방식을 이해해야합니다.

— 존 레이너
소스

"일부 데이터 요소가 NULL로 전달되면 데이터가 데이터베이스에서 데이터베이스 널로 보간되는 것을 볼 수 있습니다." -연결된 SO 질문 / 허용 된 답변에이 내용이 표시되지 않습니까?

— MrWhite

2

나는 문제가 조잡한 프로그래밍과 일부 SQL 구현의 잘못된 디자인 때문이라고 생각합니다. "널"이름은 항상 따옴표로 표시하고 해석해야합니다. 데이터베이스 값인 null은 항상 따옴표없이 표시해야합니다. 그러나 임시 코드를 작성할 때는 "무엇이든 할 것"패러다임에 빠지기 쉽고 인용 부호없는 형태의 문자열로 여겨지는 것을 받아들입니다.

이것은 다른 유형의 데이터라는 사실에 의해 더욱 복잡해집니다. 예를 들어 숫자는 해석이 모호하지 않기 때문에 어느 형식으로나 받아 들여질 수 있습니다.

— ddyer
소스

SQL을 사용하여 응용 프로그램을 제대로 구현하지 않았 습니까? RDBMS 자체의 심각한 구현은 이것에 취약하지 않습니다 (심각한 응용 프로그램이없는 것처럼!)

— underscore_d

0

근본적으로 문제는 "널 (null)"이라는 용어는 두 개의 서로 다른 데이터베이스 개념이 적용되며 때로는 컨텍스트를 사용하여 서로 구별하는 것입니다.

알려진 값이없는 것
가치가없는 것으로 알려진 것

상황에 따라 이러한 개념을 구별하기에 충분할 수 있지만 실제로 그렇지 않은 경우가 있습니다. 예를 들어, 검색어를 보유하기 위해 레코드를 사용하는 경우 "이름이없는 [다른 사람은 이름없이]"라는 말과 "이름이 [ 무엇이든]하지만 성을 모르는 사람입니다. " 많은 데이터베이스 엔진은 하나의 의미 또는 다른 의미에 대한 편견을 가지고 있지만 모두 동일하지는 않습니다. 데이터베이스 엔진이 한 방향으로 작동 할 것으로 예상하는 코드는 다르게 실행되는 다른 엔진에서 실행될 경우 오작동 할 수 있습니다.

— 슈퍼 캣
소스

문자열에 값이없는 것으로 알려진 경우 값은 null 문자열이 아닌 빈 문자열이어야합니다.

— 바이런 존스

0

기존 답변의 대부분은 응용 프로그램의 비 SQL 부분에 중점을 두지 만 SQL에도 문제가있을 수 있습니다.

사용자의 성을 사용할 수없는 레코드를 필터링하도록 지시받은 경우 SQL을 잘 모르는 사람이 필터를 작성할 수 있습니다 WHERE u.lastname != 'NULL'. SQL이 작동하는 방식 때문에 u.lastname IS NOT NULL모든 NULL레코드가 필터링 되는지 여부를 확인하는 것으로 나타납니다 . 모든 비 NULL기록은 남아 있습니다.

의 경우를 제외하고는 u.lastname == 'NULL'테스트 중에 사용 가능한 레코드가 없었을 수 있습니다.

SQL이 일종의 프레임 워크에 의해 생성되는 경우, 프레임 워크가 NULL매개 변수 가 없는지 확인하기 위해 쉽게 액세스 할 수있는 방법을 노출하지 않으며 누군가가 "이봐, 내가 문자열을 전달 NULL하면 내가 원하는 것을 정확하게 수행합니다! "

— hvd
소스