성과 이름을 별도로 모델링

새로운 시스템을 설계 할 때 어떤 주장을 고려해야하며 사람의 이름을 하나의 필드로 저장하거나 이름 / 성으로 별도로 저장해야합니까?

단일 필드의 장점 :

• 더 간단한 UI
• 매우 긴 이름을 가진 사람의 이름을 입력하려고 할 때 모호함이 없습니다 (종종 성 / 이름 임).
• 제목을 처리 할 때 복잡성이 줄어 듭니다 (예 : "MD"또는 "Dr."을 입력하기 위해 별도의 필드가 필요 없음)

분할 필드의 장점 :

• "Dear Mr X"또는 "Dear Julie"와 같은 개인 커뮤니케이션이 가능합니다.
• 소비 된 웹 서비스에 성 / 이름이 별도로 필요한 경우 쉽게 제공 할 수 있습니다.
• 엄격한 식별 요구 사항 (예 : 의료, 정부 등)이있는 모든 산업에 더 적합
• 항상 단일 현장 대안으로 돌아갈 수 있으므로 더 안전한 선택

당신은 어떤 보는가 추가 위에 나열되지 않은 인수를?

업데이트 : 문제는 각 솔루션에 대해 추가 (= 질문에 나열되지 않음) 인수 를 나열 할 수 있다는 것입니다. 가능한 장단점 대신 의견을 제시하면 토론이 잘못된 방식으로 진행된다고 생각합니다. 각 개발자는이 문제에 대한 결정을 내려야합니다.이 질문의 목적은 필요한 경우 평가할 수있는 사소한 인수 목록을 작성하는 것입니다.

이름과 성은 유용한 개념이 아닙니다. 국가마다 이름이 다르게 작동합니다. 대부분의 아시아 국가에서 이름은 먼저 작성되지만 여전히 정렬에 사용되므로 이름을 입력하면 정렬이 잘못되거나 성으로 표시되어 표시됩니다. 그리고 아이슬란드와 같이 가족 이름을 전혀 사용하지 않고 아버지의 이름을 사용하는 국가가 있습니다. 그래서 그들은 단순히 주어진 이름으로 정렬합니다.

“이름”과“성”(또는“성”)이라는 용어는 이와 관련하여 더 낫지 만 절대적으로 필요한 경우가 아니라면 여전히 피할 수 있습니다 (예 : 여권과 같은 공식 문서에 필요한 경우). 그들은 단지 일을 더 복잡하게 만듭니다.

• "Dear Mr X"또는 "Dear Julie"와 같은 개인 커뮤니케이션이 가능합니다.

주어진 사람을 이름, 성 또는 무엇으로 전화할지 모를 경우를 제외하고. 그리고 비난을받는 언어로 시작하지 마십시오 . 일반적으로 명사에서 비난을 받을 수는 없습니다 . 아니요, 단순히 사용자에게 무엇을 호출해야하는지 묻는 것이 좋습니다.

• 소비 된 웹 서비스에 성 / 이름이 별도로 필요한 경우 쉽게 제공 할 수 있습니다.

만약 . 다른 서비스에 의존하는 경우 잘못된 선택에 잠겨 있습니다. 자신의 디자인에는 이점이 없습니다.

• 엄격한 식별 요구 사항 (예 : 의료, 정부 등)이있는 모든 산업에 더 적합

아니요, 이것에 대한 잘못된 선택입니다. 공식 문서는 일반적으로 "이름"과 "성"(또는 "가족 이름")이라는 용어를 사용하는데, 이는 덜 모호합니다.

• 항상 단일 현장 대안으로 돌아갈 수 있으므로 더 안전한 선택

실제로 아시아 이름이 모호하기 때문에 그렇게 할 수는 없습니다.

중요한 유일한 주장은 시스템의 요구 사항은 무엇입니까?

하나의 문화 만 다루어야합니까? 그렇다면 그 문화를 따르십시오. 그렇지 않으면 다른 사람들이 지적했듯이 국제화 계획을 세우십시오.

정부 양식, 건강 관리 또는 기타 법적 / 시스템 요구 사항을 처리하기위한 데이터가 필요합니까? 그 지시를 따르십시오. 그것이 성과 이름을 의미한다면 그렇게하십시오. 다른 의미가 있다면 그렇게하십시오.

이름과 성을 가진 API에 대한 요구 사항이 있습니까 (또는 YAGNI를 무시할만큼 충분한가)? 거기에 맞는 것을하십시오.

개인화 된 커뮤니케이션이 필요한 경우 누군가에게 선호하는 이름을 물어 보는 것이 합리적입니까?

시스템 요구 사항에 따라 수행 할 작업이 결정됩니다. 해야 할 일을하고 나머지는 YAGNI하십시오.

이름을 표시 및 / 또는 활용하는 방법이 두 가지 이상인 경우 별도의 필드가 필요할 수 있습니다. 데이터 입력과 함께 사용자에게 데이터 활용 방법을 보여주는 피드백을 제공 할 수 있습니다. 이들을 결합하면 향후 단일 필드로 변환 될 수 있습니다.

인사말 또는 표시 이름 : 이름 + 성 구성 / 분류 : 성, 이름으로 표시되는 레이블이 있습니다.

나중에 이것이 어떻게 사용 될지 확실하지 않으면 분할 이름으로 시작한 다음 실제로 필요한 모든 것을 알면 단일 필드로 결합 할 수 있습니다. 단일 이름 필드를 성과 이름으로 나누는 알고리즘을 작성하는 것은 어렵지 않지만, 소수의 사람들은 실수를 저지르고 사람들은 실제로 자신의 이름을 가진 실수를 좋아하지 않습니다. 분할 필드를 사용하면 사용자는 이름이 어떻게 사용되는지 볼 때 이름을 입력하는 방법을 조정할 수 있습니다. 영구적 인 단일 이름 필드에 그것들을 결합하는 것은 덜 위험합니다.

@JanHudec이 말한 많은 것에 동의하지만, 조금 확장하고 싶습니다.

• 실제 요구 사항이 무엇인지 알아야하지만 정보를 다시 결합한 후 분리하는 것보다 정보를 결합하는 것이 더 쉽습니다.
• 로케일과 문화에 따라 규칙이 다를 수 있으므로 정렬은 항상 어려운 문제입니다.
• 많은 문화권이 당신의 문화와 맞지 않아서 잘못된 가정으로 이어집니다. (이것은 1 월의 가장 큰 포인트입니다)

용어는 중요하다

같은 조건 지정된 이름 과 성 또는 가족의 이름은 의미 론적 의미를 가지고 있고, 데이터베이스는 항상 데이터의 의미를 반영해야한다. 이름 및 성과 같은 용어는 일반적으로 이름의 작동 방식에 대한 영어와 미국의 아이디어를 기반으로하는 위치 적 의미를 갖습니다. 데이터 의미론에 적절한 용어를 사용하십시오.

얼마나 분해해야합니까?

의 개념이 있습니다 제목 (씨 박사 부부 등) 또는 서수 (주니어, 시니어, III 등), 심지어 인증 에 따라 중요 할 수 있습니다 (박사, 석사, PCAM 등) 맥락과 목적.

많은 로케일에는 여러 가족 이름 (부모 및 모성)이라는 개념이 있으며 일부에는 없습니다. 양식을 작성할 때, 때때로 사람들은 어떤 이름을 사용할 것인지에 대해 어려운 선택을해야합니다. 예를 들어 미국식에서 "성"에 대한 친자 이름을 사용하거나 아버지의 이름 (Janson)에 따라 성 ).

미국에서는 하나 이상의 중간 이름을 갖는 것이 일반적이지만 가족 외부에서는 종종 무시됩니다.

정렬

정렬 이름 전용 필드를 갖는 데 도움이됩니다. 그렇게하면 레코드를 만들 때 규칙을 명확하게 할 수 있습니다. 또한 국제 경계에 걸쳐 올바른 순서로 이름이 정렬되도록합니다.

일반적인 관행

실제 요구 사항에 따라 이름에 대한 정확성이 결정됩니다. 정부 또는 은행 웹 사이트를 만드는 경우 Facebook과 같은 비공식적 인 것보다 이름을 저장하고 처리하는 데 더 많은 요구 사항이 있습니다.

비공식 가이드 라인

• 사용자가 어떻게 알고 싶어하는지 설명하는 필드가 하나 있습니다.
• 정렬 및 표시는 하나의 이름을 사용합니다

반 정규 지침

• 닉네임에 대한 하나의 필드 또는 사용자의 주소 지정 방법
• 이름과성에 대해 하나씩 두 개의 필드가 있습니다 (성은 선택 사항이어야 함).
• 로케일과 주어진 / 성 콤보를 기준으로 정렬 필드 계산
• 사용자에게 직접 주소를 지정할 때 닉네임을 사용하십시오
• 사람을 나열 할 때 정식 이름을 사용하십시오.

공식적인 지침

• 지원하는 엔터티에 대한 기존 정책 및 절차에 따라 결정됩니다.
• 지원할 최대 이름 부분 수만큼 필드가 필요하며 의미에 따라 이름이 지정됩니다.
• 반 정형 경우와 마찬가지로 정렬을 처리하는 정렬 필드를 포함합니다.
• 또한 디스플레이는 일반적으로 기존 정책 및 절차에 따라 결정됩니다. 그들에게 익숙해 져야합니다.

@JanHudec이 지적하고 동의하는 것 외에도 많은 국가에서 사람들이 하나 이상의 성을 가지고 있으므로 단일 성 필드는 관련이 없을 수 있습니다. 예를 들어 스페인의 사람들은 두 개의 성이 있으며 상황에 따라 둘 중 하나만 사용합니다.

또한 일부 문화권에서는 사람들이 성으로 전화 할 때 무례한 것처럼 보일 수도 있고 다른 경우에는 반대 일 수도 있으므로 가정에 따라 커뮤니케이션을 개인화해서는 안됩니다.

또한 일부 문화권에서는 'Mrs'vs 'Ms'와 같은 형식에 중점을 두며 특정 경우에 따라이 단어를 이름 또는 성과 결합 할 수도 있습니다.

따라서 단일 이름 필드와 사용자가 사용자에게 넘기는 방법을 암시하는 추가 필드가있는 솔루션을 기대합니다. 온라인으로 티켓을 구입할 때 많은 항공사가하는 것과 유사합니다. 이렇게하면 언급 한 외부 웹 서비스에 필요한 경우 이름을 분할하는 방법의 문제를 해결할 수도 있습니다.

@JanHudec과 @KjMag가 지적한 것에 더 덧붙이면 영어와 매우 가까운 문화 / 언어에서도 이것이 문제가됩니다. 예를 들어 독일어를 사용하십시오. Vornamen, First name, Nachnamen, Last names 및 Rufname이라는 개념이 있습니다. 예를 들어 아버지를 예로 들면, 그는 3 개의 이름을 가지고 있으며, 그의 출생 증명서에는 Christoph Stephan Andreas 순서로 나열되어 있습니다. 그리고 그는 성이 하나 있습니다. 그 사람의 이름이 무엇이라고 생각하십니까?

정답은 Andreas입니다. 그것은 그의 Rufname이며, 미국에서는 그것을 미국식 템플릿에 맞는 그의 첫 번째 이름으로 넣습니다. 그래서 당신은 독일에서 당신의 이름의 마지막 이름은 당신이 불린 이름이지만 내 동생이 있다고 Christoph Sebastian Herbert Maria라고 가정 할 수 있습니다. (이제 우리는 바바리아 인이다.) 또는 나의 여동생 크리스틴 가브리엘. 그들이 이름이 뭐라고 생각합니까? 세바스찬과 크리스틴.

나는 전체 이름에 대한 하나의 필드를 말하는 답변의 세 번째입니다. 그리고 나는 그것에 덧붙일 것입니다 : 아마 성 / 가족 이름에 다른 필드를 추가하고 질문을 제기하십시오 : 당신은 어떤 이름으로 목록에 정렬됩니까? 그리고 마지막 필드는 어떻게 다루고 싶습니까?

전역 응용 프로그램을 사용하려는 경우 사람의 이름을 문자열 배열로 모델링 할 수 있습니다. 예를 들어 영화 관료주의에서 대통령의 이름을 생각해보십시오.

• 드웨인 엘존도 마운틴 듀 허버트 카마초

그의 이름입니다. 이름은 배열에 6 개의 요소를 포함합니다. 미국 문화권의 경우 이름은 배열의 첫 번째 요소 (Dwayne)이고 성은 배열의 마지막 요소 (Camacho)입니다. 그러나 항상 그런 것은 아닙니다.

이름이 실제로 다른 요소 / 지역에서 작동하는 방식에 따라 이름이 실제로 마지막 요소 인 경우 "이름"이름을 결정하기 위해 문화 별 규칙을 적용 할 수 있습니다.

또한 미국의 경우 마지막 요소가 성과 다른 경우가 있습니다.

• 드웨인 엘존도 마운틴 듀 허버트 카마초 주니어

따라서 이름 접미사 필드 또는 올바른 성을 얻기 위해 문화권을 기반으로 알려진 접미사를 찾는 마지막 요소를 구문 분석해야 할 수도 있습니다.

따라서 이름을 하나의 요소 (전체 이름)에 저장 한 다음 "표준화 / 위생"루틴을 적용하여 필요에 따라 특정 요소를 구문 분석하는 것이 좋습니다. 주소에도 비슷한 전략이 있습니다. 일반적으로 하나의 문자열로 수집 된 다음 서비스로 전송되어 파트를 구문 분석합니다.