反对将联系方式合并到单个字段中的论点是什么？
我们有一位客户坚持将联系方式（此时是名字和姓氏）放入单个字段中。以鲍勃·史密斯先生和简·史密斯夫人为例。鲍勃先生和简夫人将被输入到名字字段中，史密斯将被输入到姓氏字段中。如果联系人的姓氏不同或者名字中存在连字符，情况就会变得更加混乱。客户只想要一条联系人记录，因此他们提出了这个系统并自行实施。
我们的系统是围绕联系人设计的，每个人都旨在成为单独的联系人，甚至已婚。由于我们必须分配给人员和需要保留的注释的一些属性，因此以联系人为中心的方法是最好的。我们处理的案例中大约有1/3出现上述问题。
在内部，我的团队讨论了如何向客户推销数据库的设计方式。我们将套用信函和联系人列表列为保持数据整洁和在我们设计的字段中的主要原因。例如，使用我们的建议，客户将可以更精细地控制套用信函的创建和数据排序。
对于我们如何向客户销售这个产品有什么建议吗？
We have a customer that insists on putting contact details, at this time first and last names, into a single field. Take, for example, Mr. Bob Smith and Mrs. Jane Smith. Mr. Bob and Mrs. Jane would be entered into the first name field and Smith would be entered into the last name. It gets messier if the contacts have different last names or if there is a hyphenated name. The customer only wants one contact record so they came up with this system and implemented it on their own.
Our system is designed around contacts and each individual person is intended to be an individual contact, even married. Due to some of the attributes we must assign to people and notes we need to keep, a contact-centric approach is best. The above issue occurs in about 1/3 of the cases we handle.
Internally, my team has discussed how to sell the customer on using the database the way it was designed. We listed form letters and contact lists as being the main reasons for keeping the data clean and in the fields we designed. For example, using our recommendation, the customer will have much more granular control over form letter creation and sorting of data.
Any suggestions for how we sell this to the customer?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
告诉他们从您的系统中获得的内容与输入的内容一样好。如果他们想要输入不一致的数据，他们将付出的代价是将来无法生成信件或邮件列表。
他们可能需要自己经历惨痛的教训才能学到这个教训。我发现切换姓名会出现更多问题，例如，输入 Smith 作为名字，Bob 作为姓氏。
另外，您可以将这两个字段都设置为必填吗？
听起来他们要输入的内容类似于AddressLine1、AddressLine2。这只是一个糟糕的设计，我以为你有 2 个姓名字段，但他们只会在其中一个字段（名字）中输入数据。
当他们提出要求时，你会尽力帮助他们。他们将得到他们应得的系统。
Tell them what they can get out of your system is only as good as what gets put in. If they want to enter inconsistent data, the cost they'll pay down the line is the inability to generate letters or mailing lists in the future.
They may need to learn this lesson the hard way for themselves. I see more problems with switching the names, for example, entering Smith as the first name and Bob as the last.
Also, can you make both fields required?
It sounds like what they want to enter is similar to AddressLine1, AddressLine2. It's just a poor design, I thought you had 2 name fields but they would only enter data in one of them (the first name).
All you can do it try to help them when they ask for it. They'll get the system they deserve.
只需向您的客户展示数据库设计的标准形式即可：
> http://www.phlonx.com/resources/nf3/
告诉他这些范式旨在使数据库随着时间的推移变得更易于管理并变得更加灵活。
Just show your customer the normal forms for database design:
> http://www.phlonx.com/resources/nf3/
Tell him that these normal forms are designed to make the database more manageable over time and make it more flexible.
您不能创建一个将名字和姓氏放在一起的视图吗？对于某些服务器，您还可以创建可编辑视图...这样您的客户会很高兴，并且数据将标准化存储。
Can't you just create a view that holds First and Last name together? For some servers you can also create editable views... So your customer will be happy and data will be stored normalized.
我会尝试用金钱和时间来表达。您将花费更多的时间尝试将重复项排除在设计中的数据库之外，更多的时间构建相关的报告或查询（不断地必须解析块名称字段......他们也想将地址全部放在一个中吗？！？ ），如果他们想将数据发送给第三方进行分析和指标，则需要更多资金来清理数据（无论是他们自己还是其他人）。
听起来他们不想放弃他们的设计，部分原因可能是他们理解它。您可能想一开始尝试以某种方式满足他们，并让他们参与对设计进行渐进式改进的过程。这样他们就可以看到并理解现在可能超出他们想象的好处，将他们推出舒适区。他们必须相信你会照顾他们的孩子:)
I'd try to put it in terms of money and time. You're going to spend more time trying to keep duplicates out of a db with their design, more time building relevant reports or queries (constantly having to parse a block name field... do they want address all in one too?!?), more money to scrub the data (either themselves or someone else) if they ever want to send the data to a third party for analysis and metrics.
It sounds like they don't want to let go of their design, maybe partly because they understand it. You may want to try and meet them halfway somehow at first, and involve them in the process of making incremental improvements to the design. That way they can see and understand the benefits that right now may just be over their head, pushing them out of their comfort zone. They have to trust you with their baby :)
最好的论点是，除非数据库将内容放在它们所属的位置，否则您不必对数据库的行为负责。
如果他们想向每个“家庭”发送一封邮件，那么我确信您的应用程序可以做到这一点。 （可能已经这样做了。）你们只需要了解“家庭”的含义即可。由于可能有出租房间或长期客人，因此并不总是意味着“每个地址只能寄一封邮件”。
FWIW，我做这件事已经几十年了，我仍然发现医生和律师（及其员工）是最难打交道的人。有一次，我从会议中走出来（当然，失去了竞标合同的机会），这时一位医生的 IT 人员站起来，用拳头敲击桌子，一遍又一遍地对我尖叫：“医生是不是人！医生不是人！”。
The best argument is that you won't be responsible for the behavior of the database unless they put things where they belong.
If they want to make a single mailing to each "household", then I'm sure your app can do that. (Probably already does.) Y'all just have to come to terms on what "household" means. Since there may be rented rooms or long-term guests, it doesn't always mean "only one mailing piece per address".
FWIW, I've been doing this stuff for decades, and I still find doctors and attorneys (and their staffs) the hardest people to deal with. One time, I walked out of a meeting (and, of course, lost the chance to bid on the contract) when a doctor's IT guy stood up, pounded his fist on the table, and screamed at me over and over, "Doctors are not people! Doctors are not people!".