2 Вопрос: Как разработать таблицы сущностей для сущностей с несколькими именами

вопрос создан в Thu, May 2, 2019 12:00 AM

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

Первоначальный анализ таблиц выглядит следующим образом:

CREATE TABLE dbo.Customer (
CustomerId INT IDENTITY(1,1) NOT NULL --PK
 -- other fields below )


CREATE TABLE dbo.CustomerName (
CustomerNameId INT IDENTITY(1,1) NOT NULL -- PK
,CustomerId INT -- FK to Customer
,CustomerName VARCHAR(30)
,IsPrimaryName BIT)    

Однако имя клиента является частью сущности «Клиент», и я считаю, что оно принадлежит таблице «Клиент». Есть ли лучший дизайн для этой ситуации?

Спасибо

    
0
  1. Может ли клиент иметь много альтернативных имен или только 1? Если их много, то вам понадобится вторая таблица (особенно, если «многие» - это не поддающееся количественному определению число), если только одна, тогда вы можете использовать одну таблицу (с их основным и альтернативным именем в качестве отдельных столбцов).
    2019-05-02 14: 54: 33Z
  2. Вместо использования флага в таблице CustomerName (которая связана с собственными проблемами обслуживания), вместо этого можно сохранить основное имя в таблице Customer как FK для CustomerName таблица.
    2019-05-02 14: 54: 43Z
  3. Может быть, лучше оставить основное имя в таблице Customer. Это имя всегда одно, не так ли?
    2019-05-02 14: 56: 01Z
  4. @ Larnu, у него может быть несколько альтернативных имен.
    2019-05-02 14: 56: 28Z
  5. @ DenisRubashkin, я могу оставить его в таблице Customer, но у меня есть две альтернативы: сохранить его и в CustomerName - и в этом случае я должен его поддерживать в двух местах, или оставить его только в Customer - и в этом случае мне нужно запросить обе таблицы, если мне нужно найти список имен для Customer. Не уверен, какое решение будет лучшим
    2019-05-02 14: 59: 36Z
2 ответа                              2                         

Лично я бы сохранил Основное имя в таблице Customer и создал бы таблицу «AlternateNames» с отношением ноль-ко-многим к Customer.

Это потому, что, по-видимому, большую часть времени при возврате данных о клиентах вы будете заинтересованы только в возврате основного имени. И, вероятно, основная (если не единственная) причина, по которой вы хотите использовать альтернативные имена, заключается в поиске клиентов при предоставлении альтернативного имени.

    
1
2019-05-02 15: 15: 51Z
  1. спасибо! альтернативные имена используются для некоторых проверочных операций, но мне также понадобится основное имя при отображении всех имен.
    2019-05-03 07: 04: 50Z

К сожалению, это слишком долго для комментария.

Прежде чем понять это, нужно больше информации.

  1. Нужна ли дополнительная информация для имен? Например, язык, название или дата создания?
  2. Имена уникальны? Уникальность в клиенте или во всех именах?
  3. Являются ли первичные имена уникальными?
  4. Должен ли каждый клиент иметь основное имя?
  5. Как часто основное имя меняется на альтернативное имя? (В отличие от простого обновления имени.)
  6. Запрашивая данные, узнаете ли вы, является ли имя основным или альтернативным именем? (Или их все нужно сравнивать?)

В зависимости от ответа на этот вопрос соответствующая структура данных может иметь некоторые хитрые нюансы. Например, если у вас есть флаг для определения основного имени, может быть сложно убедиться, что ровно одна строка имеетs значение установлено - особенно при обновлении строк.

Примечание. Если вы обновите вопрос ответами, я его удалю.

    
0
2019-05-02 15: 20: 49Z
  1. Вот ответы: 1. Нет, имени достаточно 2. Да, имена уникальны 3. Да 4. Да, оно должно иметь основное имя 5 Не часто, но вы можете иметь клиента с 3,4 альтернативными именами. Если новое имя идентифицировано, оно должно существовать в альтернативных именах. Это не должно быть обновлено нигде. 6. Основное имя будет отображаться с клиентом. Альтернативные имена будут использоваться в приложении пользователями для проверки разных вещей, поэтому им нужен полный список возможных имен для клиента.
    2019-05-03 07: 09: 44Z
источник размещен Вот