需要帮助命名字段（和表）

I'm creating a new table which is related to a Contacts table (where I store first name, last name etc).

我正在创建一个与Contacts表相关的新表(我存储名字,姓氏等)。

The table has:

该表有:

int Id  (PK, Identity)
int ContactId  (FK)
int Type (this identifies whether the following is an email, tel, fax etc.)

nvarchar(40) [I need a name for this one]

The nvarchar field is basically storing either abc@abc.com, or +1 567 555-2934 x 12, or whatever else somebody would enter as a way to contact somebody else. Email, Phone, IM Name, Fax Number etc.

nvarchar字段基本上存储为abc@abc.com或+1 567 555-2934 x 12,或者其他任何人可以输入的方式来联系其他人。电子邮件,电话,IM名称,传真号码等

I have no idea how to name that field, or the table containing this stuff. I can't name it "emailAddress" as it may be a phone number and vice versa. And I don't want to name it "emailOrPhoneOrXYZ" of course.

我不知道如何命名该字段,或包含这些东西的表。我不能将其命名为“emailAddress”,因为它可能是电话号码,反之亦然。我当然不想将它命名为“emailOrPhoneOrXYZ”。

Any idea?

10 个解决方案

#1

I had a similar problem with a table at the sysytem I'm currently developing.

在我正在开发的系统中,我遇到了类似的问题。

So we named the table ContactComplements and the field simply Value.

所以我们将表名称为ContactComplements,并将字段命名为Value。

#2

Well, I might start by renaming "Id" and "type" - those aren't very descriptive. How about "ContactInfoID" and "ContactInfoType". The final field could then be reasonably titled "ContactInformation".

好吧,我可以从重命名“Id”和“type”开始 - 那些不是很具描述性。 “ContactInfoID”和“ContactInfoType”怎么样?然后,最终字段可以合理地标题为“ContactInformation”。

You're right that you shouldn't use a silly name like "emailOrPhoneOr...", because that prohibits you from storing additional types of contact information in the future.

你是不对的,你不应该使用像“emailOrPhoneOr ...”这样的愚蠢名称,因为这会阻止你将来存储其他类型的联系信息。

Also consider that a tinyint is likely more than large enough for your "type" field, provided that your rdbms supports tinyints.

还要考虑一个tinyint可能比你的“类型”字段足够大,只要你的rdbms支持tinyints。

#3

In the context of a Contacts table you can consider Detail for the field.

在“联系人”表的上下文中,您可以考虑该字段的“详细信息”。

#4

Ideally, when designing relational databases, you should avoid storing different types of information in the same field when possible.

理想情况下,在设计关系数据库时,应尽可能避免在同一字段中存储不同类型的信息。

One thing to consider, there are times where it makes sense to denormalize your data, you should may want to consider that in this situation. (see http://en.wikipedia.org/wiki/Denormalization)

有一点需要考虑,有时候对数据进行非规范化是有意义的,在这种情况下你可能应该考虑这一点。 (见http://en.wikipedia.org/wiki/Denormalization)

At a minimum, I think it would make sense to use at least 2 tables, one for Email/IM and one for phone. For the email/IM table, add flags indicating if the address was Email or IM (or both if both flags set), as yahoo and others use email as the IM ID.

至少,我认为使用至少2个表是有意义的,一个用于电子邮件/ IM,一个用于电话。对于电子邮件/ IM表,添加标志,指示地址是电子邮件还是IM(或两者都设置了两个标志),因为雅虎和其他人使用电子邮件作为IM ID。

#5

--table-per-class strategy:

--baseclass
table ContactItem
    column Id --pkey

--subclass
table ContactItemEmail
    column Id --pkey, fkey ContactItem.Id
    column Email

--subclass
table ContactItemPhone
    column Id --pkey, fkey ContactItem.Id
    column Phone

#6

I'd name the table ContactDetails and the field ContactString.

我将表命名为ContactDetails,并将字段命名为ContactString。

#7

I would just name it Contact. It's generic enough that it could apply regardless of the actual type of information contained therein but also implies that it's used for contacting someone.

我只想把它命名为Contact。它足够通用,无论其中包含的实际信息类型如何,它都可以应用,但也暗示它用于联系某人。

#8

As you are maintaining key/value pairs that are associated with your CONTACT table, you could name it CONTACT_PROPERTIES. 'Value' would be as good a name as any for the field in question.

在维护与CONTACT表关联的键/值对时,可以将其命名为CONTACT_PROPERTIES。 “价值”将与所涉及的领域一样好。

#9

MainContact

#10

Presumably this is a free text element with no associated domain value validation i.e. user could type anything in here and it would be an acceptable value. In our data dictionary we tend to call these 'notes'.

据推测,这是一个*文本元素,没有相关的域值验证,即用户可以在此输入任何内容,这将是一个可接受的值。在我们的数据字典中,我们倾向于称这些“笔记”。

#1