姓と名を別々にモデリングする

新しいシステムを設計する際に、誰かの名前を考慮すべきであり、人の名前を1つのフィールドとして保存するか、名/姓として別々に保存する必要がありますか？

単一フィールドの長所：

• シンプルなUI
• 非常に長い名前を持つ人の名前を入力しようとしてもあいまいさはありません（多くの場合、姓/名であることが明らかではありません。）
• タイトルを処理する際の複雑さの軽減（「MD」または「Dr.」を入力するための別のフィールドは不要です）

スプリットフィールドの長所：

• パーソナライズされたコミュニケーションは可能です「Dear Mr X」または「Dear Julie」
• 消費されたWebサービスが姓/名を個別に必要とする場合、簡単に提供できます。
• 厳格な身元確認要件のある業界（医療、政府など）に適した選択肢
• 常に単一フィールドの代替に戻ることができるため、より安全な選択

あなたはどのご覧ください追加の上に一覧表示されていない引数を？

更新：問題は、ソリューションごとにどの追加（=質問にリストされていない）引数をリストできるかです。賛否両論の可能性の代わりに意見を述べることは、議論を間違った方向に進めると思います。各開発者はこの問題について決定する必要があります。この質問の目的は、必要に応じて評価できる重要な引数のリストを作成することです。

名と姓は有用な概念ではありません。名前は国によって異なります。ほとんどのアジア諸国では、姓が最初に書かれていますが、それでもソートに使用されています。したがって、姓に名前を付けると、ソートが間違っているか、姓になって表示されます。そして、アイスランドのように、姓をまったく使用せず、代わりに父親の名を使用する国があります。したがって、彼らは単に与えられた名前でソートします。

「名」と「姓」（または「姓」）という用語は、この点で優れていますが、絶対に必要な場合を除き、それらは避けます（パスポートなどの公式文書には必要があるため、必要です）それらは物事をより複雑にします。

• パーソナライズされたコミュニケーションは可能です「Dear Mr X」または「Dear Julie」

指定された人を名、姓、または何で呼び出すかわからない場合を除きます。そして、対格のある言語を始めてはいけません。一般的に主格から対格を導き出すことはできません。いいえ、単に何を呼び出すかをユーザーに尋ねる方が良いでしょう。

• 消費されたWebサービスが姓/名を個別に必要とする場合、簡単に提供できます。

の場合。別のサービスに依存している場合、その悪い選択に縛られています。独自の設計には利点がありません。

• 厳格な身元確認要件のある業界（医療、政府など）に適した選択肢

いいえ、これは間違った選択です。公式文書では、一般に「名」と「姓」（または「姓」）という用語を使用しますが、これらはあいまいではありません。

• 常に単一フィールドの代替に戻ることができるため、より安全な選択

実際、アジアの名前の曖昧さのために、あなたができることはそれほど明確ではありません。

重要な唯一の議論は、システムの要件は何ですか？

1つの文化にのみ対処する必要がありますか？その場合は、その文化に準拠します。そうでなければ、国際化の計画を立てる（他の人が指摘したように）。

政府のフォーム、医療、またはその他の法的/システム要件に対処するためのデータを取得する必要がありますか？それらが指示するものは何でも従ってください。それが姓と名を意味する場合、それを行います。別の何かを意味する場合は、それを行います。

名前と姓のAPIの要件はありますか（または、YAGNIを無視するのに十分な合理的な可能性がありますか）？そこで意味のあることをしてください。

パーソナライズされたコミュニケーションが必要な場合、好みの名前を誰かに尋ねて保存するのが妥当ですか？

システムの要件によって、何をするかが決まります。必要なことを行い、残りはYAGNIです。

名前を表示および/または利用する方法が複数ある場合は、おそらく個別のフィールドが必要になります。データ入力とともに、フィードバックを提供して、ユーザーにデータの利用方法を示すことができます。それらをどのように組み合わせるかは、将来的に単一のフィールドに変換することにつながる可能性があります。

表示するラベルがあります：挨拶または表示名：名+姓整理/並べ替え：姓、名

これが将来どのように使用されるかわからないときは、分割名から始めて、それが本当に必要なことに気づいたときにそれらを単一のフィールドに結合することができます。単一の名前フィールドを姓と名に分割するアルゴリズムを作成するのは難しいということではありませんが、いくつかの間違いを犯すことになり、人々は名前の間違いを嫌います。分割フィールドを使用すると、ユーザーは名前の使用方法を確認したときに名前の入力方法を調整できます。それらを永続的な単一の名前フィールドに結合することは、それほど危険ではありません。

私は@JanHudecが言ったことの多くに同意しますが、それについて少し拡張したいと思います。

• 実際の要件が何であるかを知る必要がありますが、情報を再結合してから分割するよりも、情報を結合する方が簡単です。
• ルールはロケールや文化によって異なる可能性があるため、ソートは常に課題となります。
• 多くの文化はあなたのものと一致しません、それは悪い仮定につながります。（これは1月の最大のポイントです）

用語は重要です

以下のような用語与えられた名前と姓や家族の名前はセマンティックな意味を持っており、データベースは常にあなたのデータの意味を反映すべきです。名や姓などの用語には、通常、名前の仕組みに関する英語とアメリカの考え方に基づいた位置的な意味があります。データのセマンティクスに適切な用語を使用します。

それをどこまで分解する必要がありますか？

タイトル（Mr. Dr. Mrs.など）または序数（Jr.、Sr.、IIIなど）の概念があり、さらに認定（PhD、MS、PCAMなど）もあります。コンテキストと目的。

多くのロケールには、複数の姓（父方および母方）の概念があり、一部のロケールにはありません。フォームに記入する際、使用する名前を厳密に選択しなければならない場合があります。たとえば、アメリカ形式の「姓」に父方の姓を使用したり、父親の名前に基づいて姓を見つけたりする場合（Janson ）。

アメリカでは1つまたは複数のミドルネームを持っていることが一般的ですが、家族の外ではしばしば無視されます。

仕分け

ソート名専用のフィールドを用意すると便利です。そうすることで、レコードを作成するときにルールを明確にすることができます。また、国際的な境界を越えて正しい順序で名前がソートされるようにします。

一般的な慣行

実際の要件により、名前についてどの程度正確である必要があるかが決まります。政府または銀行のWebサイトを作成している場合、Facebookのような非公式なものよりも、名前の保存と処理に関する要件が多くなります。

非公式のガイドライン

• ユーザーがどのように知られたいかを説明するフィールドを1つ持つ
• 並べ替えと表示はその1つの名前を使用します

準公式ガイドライン

• ニックネーム、またはユーザーの対処方法を入力するフィールドが1つあります
• 2つのフィールドがあり、1つは名、もう1つは姓（姓はオプション）
• ロケールと名/姓のコンボに基づいてソートフィールドを計算する
• ユーザーに直接アドレス指定するときにニックネームを使用します
• 人をリストするときに正式な名前を使用する

正式なガイドライン

• これらは、サポートしているエンティティの既存のポリシーと手順によって決まります
• サポートする名前部分の最大数と同じ数のフィールドが必要であり、それらが何であるかを意味的に命名します。
• セミフォーマルの場合のようにソートを処理するソートフィールドを含める
• また、表示は通常、既存のポリシーと手順によって決定されます。それらに慣れる必要があります。

@JanHudecが指摘したことと、私が同意することは別として、多くの国では人が複数の姓を持っているため、1つの姓フィールドは無関係かもしれません。たとえば、スペインでは、姓は2つあり、状況に応じてどちらか一方または両方を使用します。

一部の文化では、姓で人を呼ぶときは失礼に思えるかもしれないし、他の場合は反対になるかもしれないので、あなたの仮定に基づいてコミュニケーションをパーソナライズしてはいけません。

また、一部の文化では「Mrs」と「Ms」のような形式に重点を置いており、特定のケースに応じてこの単語と名または姓を組み合わせることもあります。

したがって、単一の名前フィールドと、おそらくユーザーがユーザーに向けるヒントを入力する追加フ​​ィールドを持つソリューションに傾倒します。これは、多くの航空会社がオンラインでチケットを購入するときのようなものです。これにより、言及した外部Webサービスに名前が必要な場合に名前を分割する方法の問題も解決される場合があります。

@JanHudecと@KjMagが指摘したことをさらに追加すると、英語に非常に近い文化/言語であっても、これが問題になります。たとえば、ドイツ語を考えてください。Vornamen、名、Nachnamen、姓、Rufnameという名前の概念があります。私の父を例にとると、彼には3つの名があり、出生証明書にはChristoph Stephan Andreasの順にリストされています。そして彼には姓があります。彼は何と呼ばれていますか？

正解：アンドレアス。それが彼のRufnameであり、アメリカではアメリカのテンプレートに合うように彼のファーストネームとしてそれを置きます。ドイツでは、姓の最後の名前はあなたが呼ばれた名前であると仮定するかもしれませんが、私の兄弟はクリストフ・セバスチャン・ハーバート・マリアです。（今、私たちはバイエルン人です）または妹のクリスティン・ガブリエレ。彼らは何と呼ばれる名前だと思いますか？それぞれセバスチャンとクリスティン。

私は、フルネームの1つのフィールドを言う答えを3番目にします。それに追加します：姓/姓に別のフィールドを追加して質問を投げる：リスト内でどの名前でソートされますか？そして最後のフィールド：どのように対処したいですか？

グローバルアプリケーションを使用する場合は、おそらく人の名前を文字列の配列としてモデル化します。たとえば、映画のイディオクラシーで大統領の名前を考えてみましょう。

• ドウェインエルゾンドマウンテンデューハーバートカマチョ

それが彼のフルネームです。名前の配列には6つの要素が含まれています。米国文化の場合、名は配列の最初の要素（Dwayne）であり、姓は配列の最後の要素（Camacho）です。しかし、常にそうとは限りません。

名が異なる文化/ロケールでどのように機能するかに応じて、名が実際に最後の要素である場合など、「名」を決定する文化固有のルールを適用できます。

また、米国の場合、次のような最後の要素が姓ではない場合があります。

• ドウェインエルゾンドマウンテンデューハーバートカマチョジュニア

そのため、名前のサフィックスフィールドか、カルチャに基づいて既知のサフィックスを探す最後の要素を解析して、正しいラストネームを取得する必要があります。

そのため、名前を1つの要素（フルネーム）に保存し、それに対して「標準化/衛生」ルーチンを適用して、必要に応じて特定の要素を解析する方が良いでしょう。住所についても同様の戦略が存在します。通常、これらは1つの文字列として収集され、パーツを解析するためにサービスに送信されます。