名中间名姓。 为什么不是全名？
I am trying to find a better approach for storing people's name in the table.
What is the benefits of 3 field over 1 field for storing persons name?
UPDATE
Here is an interesting discussion and resources about storing names and user experience
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（22）
您始终可以从其组成部分构造全名，但不能总是将全名解构为其组成部分。
假设您想写一封以“Dear Richie”开头的电子邮件 - 如果您有一个
given_name字段，那么您可以轻松完成此操作，但从某人的全名中找出其名字并非易事。您还可以按
given_name、family_name等进行简单搜索或排序。（请注意，我使用的是
given_name、family_name等，而不是first_name、last_name，因为不同的文化会将他们的名字顺序不同。）在一般情况下解决这个问题是很困难的 - 这里有一篇文章介绍了它有多难：代表都柏林核心区的人名。
You can always construct a full name from its components, but you can't always deconstruct a full name into its components.
Say you want to write an email starting with "Dear Richie" - you can do that trivially if you have a
given_namefield, but figuring out what someone's given name is from their full name isn't trivial.You can also trivially search or sort by
given_name, orfamily_name, or whatever.(Note I'm using
given_name,family_name, etc. rather thanfirst_name,last_name, because different cultures put their names in different orders.)Solving this problem in the general case is hard - here's an article that gives a flavour of how hard it is: Representing People's Names in Dublin Core.
尽可能保持数据干净！
如何？
仅向用户询问在您询问时绝对需要的尽可能少的事情。
如何存储名称并不重要。 重要的是，
如果您通过强制填写字段并多次重新询问用户而惹恼了他们，他们可能会感到不安并且不购买立即进入您的应用程序。 您希望始终避免不良的用户体验。
没有用户关心您在数据库中搜索他的中间名有多么容易。 他想要一种轻松、感觉良好的体验，仅此而已。
如果用户只想要一个不需要通知的“只读”帐户，而被迫输入邮政地址甚至电子邮件地址等数据，他们该怎么办？ 他们将垃圾数据放入您的系统中。 无论如何，这将使您的超级搜索和排序算法毫无用处。
因此，我的建议是在任何应用程序中，从用户处收集的信息与您为用户服务所需的信息一样少，仅此而已。
例如，如果您经营一家宠物食品网上商店，请不要在注册时询问用户他们拥有哪种宠物。 让他们可以选择在登录并感到高兴（新客户）后填写。 在他们订购实际运送到他们家的东西之前，不要询问他们的邮政地址，他们支付的东西，因此关心你有他们的确切坐标。
这将带来更好的数据质量，这是您应该关心的，而不是用户无法从中受益的技术细节......
在您的示例中，我只会要求全名（但不确定），一旦用户自愿订阅您的时事通讯，让用户决定他/她希望如何被称呼......
Keep your data as clean as you can!
How?
Ask your user only as few things as you absolutely need at the time you ask.
How you store the name does not matter. What does matter is that
If you annoy the users with mandatory fields to fill in and re-question them several times, they can get upset and not buy into your application right there and then. You want to avoid bad user experiences at all times.
No user cares how easy it is for you to search your database for his middle name. He wants to have a easy, feel good experience, that's it.
What do users do if they are forced to input data like their postal address, or even email address when they only want a "read-only" account with no notifications needed? They put garbage data into your system. This will render your super search and sort algorithms useless anyway.
Thus, my advice would be in any app to gather just as little information from your user as you really need in order to serve them, no more.
If for example you run a online shop for pet food, don't ask your users at sign-up what kind of pets they own. Make it an option for them to fill in once they are logged in and all happy (new customers). Don't ask them their postal address until they order stuff that is actually carried to their house, stuff they pay for and thus care that YOU have their exact coordinates.
This will lead to a lot better data quality and this is what you should care about, not technical details the user has no benefit from....
In your example I would just ask for the full name (not sure though) and once the user willingly subscribes to your newsletter, let the user decide how he/she wants to be addressed...
正如其他人所说，如何将全名分解为其组成部分。
你如何可靠地分解那批作品？
要了解更多信息，请参阅程序员对名称的看法。
As others have said, how do you decompose a full name in to its component parts.
How do you reliably decompose that lot?
To learn more, see falsehoods programmers believe about names.
前几天我在查找西班牙内战，发现大多数规则都有这样的例外：
下次当我开发一个必须存储名称的系统时，我将尝试一些激进的做法：根据需求进行设计。
我们将使用这些名称做什么？
根据名称的用途，我们将确定要存储多少信息。 也许我们允许用户输入所有这三个内容，包括第一种情况下的换行符（佛朗哥大元帅可能希望列出他的完整头衔和任命，如果他还没有死的话）。 也许我们提供First、Middle、Last、Generation作为选项，其余填写默认。 也许我们提供其他常见选项，例如姓氏、名字。
这与我们在 1975 年开始使用 COBOL 编程之前就使用的旧式 First、Middle、Last 形成鲜明对比，并且从那时起就“适应”了。
I was looking up the Spanish Civil War the other day, and found this exception to most rules:
Next time I'm working on a system that has to store names, I'm going to try something radical: designing from the requirements.
What are we going to use the names for?
Based on what the names will be used for, we'd determine how much information to store. Maybe we allow the user to enter all three of those, including line breaks in the first case (Generalissimo Franco might want his full titles and appointments listed, if he weren't still dead). Maybe we provide First, Middle, Last, Generation as an option, and fill in the rest as defaults. Maybe we offer other common options like Surname, Given Name.
This is in contrast to the old-style First, Middle, Last we've used since before I started programming in COBOL back in 1975, and have "made fit" ever since.
不幸的是，这有点像询问在数据库中存储数字的最佳方式是什么。 这取决于你要用它做什么——有时你想要一个 int，有时你想要一个 byte，有时你想要一个 float。 对于名称，它取决于您希望您的用户来自哪种文化、您计划如何处理这些名称（您是否会使用这些名称来连接另一个将名称存储为“姓氏、名字”的系统？ ），以及你能承受多大程度的惹恼你的用户。 如果这是一个内部 HR 应用程序，您可能会惹恼用户很多，并且对姓名组件进行非常结构化、正式的细分（有超过 3 个 - 不要忘记 mr/mrs、jr、III、多个中间名、带连字符的姓氏，如果您试图处理来自所有文化的名称，谁知道还有什么）。 如果您有一个用户可能关心也可能不关心的网络应用程序，您不能要求他们太关心。
Unfortunately this is kind of like asking what is the best way to store a number in the database. It depends on what you are going to do with it - sometimes you want an int,other times a byte, and sometimes a float. With names it depends on things like what cultures do you expect your users to come from, what you plan on doing with the names (will you be using these names to connect with another system that stores names as "last name, first name"?), and how much you can afford to annoy your users. If this is an internal HR application, you can probably afford to annoy the users a lot, and have a very structured, formal breakdown of name components (there are way more than 3 - don't forget mr/mrs, jr, III, multiple middle names, hyphenated last names, and who knows what else if you are trying to handle names from all cultures). If you have a webapp that users might or might not care about, you can't ask them to care too much.
您可能需要在 3 个单独的字段中搜索其中一个，并且连接全名的成本较低。
例如，如果您想搜索所有诺兰先生，您的查询将是
仅使用全名来执行此操作会很痛苦。
You may want to search on the 3 separate fields for one and its inexpensive to concatenate for the fullname.
e.g. If you want to search for all the Mr. Nolans your query would be
to do this with just the fullnames would be a pain.
我是英国人，只有一个名字。 我通常把它放在“姓氏”字段中，以免造成麻烦。 我通常也被迫在“名字”字段中输入一些内容，这根据定义是错误的。
任何强加除“名称”之外的内容的尝试至少在某些时候注定是错误的，有时甚至会让用户感到非常沮丧。 在印度南部、印度尼西亚和巴基斯坦（有数亿人口），单名很常见，在英国偶尔也会出现像我这样的怪人。
“第一、中间、最后”的事情非常以美国为中心。 很少有其他国家会这样考虑名字。 请停止这样做。
I'm English and only have one name. I normally put it in the 'surname' field for least aggravation. I am usually forced to put something in the 'first name' field too, which by definition is wrong.
Any attempt to impose anything more than 'Name' is doomed to be wrong at least some of the time, and sometimes be very frustrating to users. Single names are common in Southern India, Indonesia, and Pakistan (which is hundreds of millions of people) as well as the occaisional weirdo on the UK like me.
The 'first, middle, last' thing is very U.S.-centric. Few other countries think of names that way. Please stop doing it.
将字段分开可以让您支持不同的输出格式和文化（其中姓氏先写）
Keeping the fields separate allows you to support different output formats and cultures where the family name is written first
当您将姓名分解为多个字段时，可能会出现诸如
ORDER BY firstname或ORDER BY lastname之类的情况。当您将所有名称混杂到一个字段中时，这件事就不那么容易了。
Things like
ORDER BY firstnameorORDER BY lastnameare possible when you break the name up into multiple fields.Not as easy to do when you mash all names into one field.
我唯一能想到的就是用于搜索目的。 使用 [=] 搜索字段比使用 [like] 更好一些。
如果您不需要将名称显示为单独的单词，则使用单个字段。
但如果您需要做类似[亲爱的阿楚先生]之类的事情，那么也许 3 场方法会更好。
About the only thing I can think of is for searching purposes. It's a bit better to search a field using [=] rather than say [like].
If you have no need to display the name as seperate words then go with a single field.
But if you need to do something like [Dear Mr. Achu] then perhaps a 3 field approach would be better.
大多数时候，它支持书写套用信函，例如“某某先生”，或者按姓氏进行搜索/排序，这很常见。
鉴于第一个/中间/最后一个可能不适用于所有文化，可能有更好的方法。 它可能更好地表达为“非正式名称”/“正式名称”/“法定名称”或类似的名称。
尽管如此，在这一点上，第一个/中间/最后一个是很常见的，从数据输入的角度来看，这是每个人所期望的。
Most of the time it's there to support writing form letters like, "Mr. so-and-so", or to search/sort by last name which is very common.
Given that first/middle/last may not apply to all cultures, there could be a better approach. It might be better expressed as "informal name" / "formal name" / "legal name" or something like that.
Still, at this point first/middle/last is very common, and from a data entry standpoint it is what everyone expect.
事情是这样的，即使是人类也不能一直正确地做到这一点，数据太多，特殊情况也太多。 我现在可以把我的名字改成 20 个部分，中间的 13 个作为我的“名字”。 名称的各个部分可以包含任意数量的单词，并且名称的部分可以有任意数量。 有些人只有 1 个名字（没有姓氏）。 有些人有很多中间名。 有些人的名字或姓氏由几个单词组成。 有些人先列出自己的姓氏。 有些人用他们的中间名。 有些人使用的昵称与他们的名字没有明显的关系。
如果您尝试猜测软件中的这些约定，您将失败。 时期。 也许你有时会做对，甚至大多数时候，但这值得吗？ 在我看来，你应该将名字存储为一个字段，而不要试图通过使用名字来指代一个人来表现得可爱。 如果您需要有关名称的其他信息（例如昵称），请询问用户！
Here's the thing, not even humans can get this right all the time, there's just too much data, and too many special cases. I could change my name right now to be 20 parts, with the middle 13 as my "first" name. Parts of names can contain any number of words, and there can be any number of parts of names. Some people only have 1 name (no surname). Some people have lots of middle names. Some people have first or surnames composed of several words. Some people list their surname first. Some people go by their middle name. Some people go by nicknames that aren't obviously related to their given name.
If you try to guess these conventions in software YOU WILL FAIL. Period. Maybe you'll get it right some of the time, maybe even most of the time, but is even that worth it? In my opinion you should store names as one field and stop trying to be cute by using first names to refer to a person. If you need additional information about a name (e.g. a nickname), ask the user!
每个单独的名称都是一个原子数据。 当它们单独存储时，可以更容易地以不同的格式打印它们，例如名字姓氏和姓氏，名字。
Each of the individual names is an atomic piece of data. When they are stored separately then it is easier to print them out in different formats such as Firstname Lastname and Lastname, Firstname.
如果您不需要按名字、中间名或姓氏进行排序或搜索，则没有任何好处。
There is no benefit if you never need to sort or search by first, middle, or last name.
灵活性。
例如
如果某人有双桶姓氏并且没有中间名。
Flexibility.
e.g.
If someone had a double barreled last name and no middle name.
我投票赞成其中一些答案，但如果您希望避免代码中重复、冗余或混乱的串联，您始终可以使用数据库中的计算列或类中公开一致重建的名称的方法。 如果这些串联的成本很高（因为您要打印一百万条语句），则可以使用持久列。
通常，您将允许用户指定昵称或友好名称等名称，这样您就不会通过他们记录中的名称或始终使用史密斯先生来引用他们。
这一切都取决于您的要求。 如果没有预期满足的环境，就没有一个好的答案。
I voted up some of these answers, but if you are looking to avoid repetitive or redundant or messy concatenation in your code, you can always use a computed column in the database or a method in a class which exposes the name consistently reconstructed. If these concatenations are expensive (because you are printing a million statements), you can use a persisted column.
Often you will allow users to specify names like nicknames or friendly names, so that you aren't referring to them by the name in their records or always as Mr. Smith.
It all depends on your requirements. There is no single good answer without the environment it is expected to satisfy.
不确定它有多实用，但如果文化敏感性在正在开发的应用程序的上下文中很重要，也许名称应该是一个集合，集合中的每个元素都带有一个值，指示该名称是否是可寻址的“名字” ”或可寻址的“姓氏”等“头衔”或任何其他需要识别的内容。 名称 ID 可用于标识重新组成全名的元素顺序。
Not sure how practical it would be, but maybe if cultural sensitivity is important in the context of the application being developed, perhaps a name should be a collection with each element of the collection carrying a value indicating if the name is the addressable "first name" or the addressable "surname" and so on for "title" or anything else that needs to be identified. A name ID could be used to identify the order of the elements for re-composing the full name.
只需有两个字段，“全名”和“首选名称” - 很简单。 支持现有的每个名称（只要该语言具有词汇符号......所以，是的，这排除了没有书面形式的语言）。
只需确保它们以某种 unicode 格式进行处理，并且应用程序代码可以正确处理 unicode 转换。
Just have two fields, 'Full Name', and 'Preferred Name' - easy. Supports every name in existance (As long as the language has lexical symbols... So, yes, that excludes languages that do not have a written form).
Just make sure that they are handled in some unicode format, and that application code properly handles unicode conversion.
对我来说，最好存储 3 个名称，以便稍后在需要各个组件时需要进行显式解析。
To me it is simply better to store 3 names so that explicit parsing is necessary later on if the individual components are needed..
您无法总是干净可靠地将姓氏与全名分开，因此有充分的理由将其分开，因为您经常需要姓氏。 完成此操作后，有两种常见的方法：
(2) 可以说是更可取的，因为人们有时有两个以上的名字，而 (1) 在这方面更不灵活。
另外，另一个常见字段是preferred_name（除了上述字段之外）。
You can't always separate surname from full name cleanly and reliably so there's good reason to separate that because you often need surname. After you do that, there are two common approaches:
(2) is arguably more preferable because people sometimes have more than tow given names and (1) is more inflexible in this regard.
Also, another common field is preferred_name (in addition to the above).
无论哪种方式，国际化问题都可能是一个麻烦事。 某些文化首先使用姓氏，最后使用名字，这会影响名字和姓氏的概念，因此我们转向姓氏和名字字段。 等等，有些文化没有姓氏，或者姓氏会根据命名者的性别进行修改。
我们可以进入部落文化，在这种文化中，人成年后会被重新命名。 “坐牛”童年的名字是“跳獾”。
这有点啰嗦，但我要展示的是，您拥有的字段越多，设计就越准确。 至少应该有一个
not null“名字”字段和一个与整数PK关联的可选“姓氏”字段。 如果遵守上述要求，则可以添加字段而不会出现中断查询的问题。The i18n issue can be a bugger either way. certain cultures use the surname first and the given name last, that strikes the idea of first and last names so we move to fields for surnames and given names. Wait, some cultures don't have a surname or the surname is modified by the gender of the named.
We can get into tribal cultures where the person is renamed on adulthood. "Sitting Bull" childhood name was "Jumping Badger".
This is somewhat of a ramble but what I am showing is that the more fields you have the more accurate the design is. There should be at least a
not null'given name' field and aoptional'surname' field tied to aPKthat is an integer. If the aforementioned requirements are observed, fields can be added without issues of breaking queries.有些问题可以通过存储附加列（例如 PreferredName）来解决。 我们在数据库中执行此操作，并存储前缀列和后缀列。
例如
“小亨利·W·琼斯教授”，首选名字为“印第安纳·琼斯”。
Some of the issues can be solved by also storing an additional column like PreferredName. We do that in our DB and also store prefix column and a suffix column.
e.g
'Prof Henry W Jones Jnr' with preferred name as 'Indiana Jones'.