Нужна помощь в названии поля (и таблицы)

Question

Я создаю новую таблицу, которая связана с таблицей контактов (где я храню имя, фамилию и т. Д.).

Таблица имеет:

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]

Поле nvarchar в основном хранит либо abc@abc.com, либо +1 567 555-2934 x 12, либо что-либо еще, что кто-то мог бы ввести, чтобы связаться с кем-то еще. Электронная почта, телефон, имя чата, номер факса и т. Д.

Я понятия не имею, как назвать это поле или таблицу, содержащую этот материал. Я не могу назвать его «emailAddress», так как это может быть номер телефона и наоборот. И я не хочу называть это «emailOrPhoneOrXYZ», конечно.

Есть идеи?

Answer 1

У меня была похожая проблема с таблицей в системе, которую я сейчас разрабатываю.

Итак, мы назвали таблицу ContactComplements, а поле просто Value.

Answer 2

Я бы назвал таблицу ContactDetails и поле ContactString.

Answer 3

--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

Answer 4

В идеале, при проектировании реляционных баз данных, вы должны избегать хранения разных типов информации в одном поле, когда это возможно.

Одна вещь, которую следует учитывать, бывают случаи, когда имеет смысл денормализовать ваши данные, вы можете подумать об этом в этой ситуации. (см. http://en.wikipedia.org/wiki/Denormalization)

Как минимум, я думаю, что было бы целесообразно использовать как минимум 2 таблицы, одну для электронной почты / мгновенных сообщений и одну для телефона. Для таблицы email / IM добавьте флаги, указывающие, был ли адрес Email или IM (или оба, если оба флага установлены), так как Yahoo и другие используют электронную почту в качестве IM ID.

Answer 5

В контексте таблицы Contacts вы можете рассмотреть Detail для поля.

Answer 6

Ну, я мог бы начать с переименования «Id» и «type» - это не очень наглядно. Как насчет "ContactInfoID" и "ContactInfoType". Последнее поле может быть разумно названо «Контактная информация».

Вы правы, что вы не должны использовать глупое имя, такое как "emailOrPhoneOr ...", потому что это запрещает вам хранить дополнительные типы контактной информации в будущем.

Также учтите, что tinyint, вероятно, более чем достаточно велик для вашего поля типа, при условии, что ваш rdbms поддерживает tinyints.

Answer 7

Предположительно, это произвольный текстовый элемент без проверки значения соответствующего домена, т. Е. Пользователь может ввести здесь что угодно, и это будет приемлемое значение. В нашем словаре данных мы обычно называем эти «заметки».

Answer 8

MainContact

Answer 9

Поскольку вы поддерживаете пары ключ / значение, связанные с вашей таблицей CONTACT, вы можете назвать ее CONTACT_PROPERTIES. «Значение» будет таким же хорошим именем, как и любое другое для рассматриваемой области.

Answer 10

Я бы просто назвал это Контакт. Он достаточно универсален, чтобы его можно было применять независимо от фактического типа содержащейся в нем информации, но также подразумевает, что он используется для связи с кем-либо.