Вопрос о структуре данных - PullRequest
Новая
       2

Вопрос о структуре данных

1 голос
/ 12 августа 2011

Как лучше всего справиться с этим сценарием?

У меня есть клиент Модель (таблица) содержит контактную информацию для клиентов Модель Prospect (таблица) содержит контактную информацию для посетителей магазина, которые не являются покупателями У меня есть модель возможности (таблица), когда покупатель или покупатель посещает магазин.

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

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

Это правильный способ обработки условной ассоциации?

Когда дело доходит до представления, я застрял на том, как мне создать ассоциацию клиентов или потенциальных клиентов?

1 Ответ

1 голос
/ 13 августа 2011

Я студент информатики, и это мое понимание отношений с БД:

Поскольку у вас есть два типа «Люди» - «Клиент» и «Перспектива», потенциально у вас может быть таблица «Человек». В таблице Person будут храниться любые общие данные между обоими объектами (FirstName, LastName, Address1, Address2, City, State, Zip и т. Д.).

Чтобы указать, что Person является Перспективой, у вас должна быть таблица Prospect, в которой будет PersonId для связи с таблицей Person. В этой таблице вы можете хранить более конкретные атрибуты о потенциальном клиенте.

То же самое относится и к Customer - у вас будет таблица Customer - в которой будет столбец PersonId для ссылки на таблицу Person и любые специфические атрибуты для объекта Customer.

Теперь у вас есть база данных, в которой вы можете получать другие сущности ... скажем, сущность Сотрудника> у вас есть базовая сущность Лица, с которой нужно начинать. И ваша таблица Employee будет ссылаться на нее, а также будет иметь другие пользовательские столбцы для данных сотрудника.

Имеет ли это смысл?

Или, может быть, я ошибаюсь :). Пожалуйста, поправьте меня, если я ошибаюсь, потому что я еще студент.

Я думаю, что вы застряли, потому что теперь у вас есть два поля в записи «Возможность» (Клиент ИЛИ проспект), одно из которых ДОЛЖНО быть нулевым. В предложенной мной модели ваша возможность будет связываться с персоной, в которой вы сможете определить собственные бизнес-правила, ограничивающие, скажем ... возможность сотрудника (что на самом деле может быть неплохой идеей).

Для лица, на которое делается ссылка в вашей модели возможностей, это не будет ICollection (поскольку вы специально сказали, что возможность может иметь ТОЛЬКО один человек). Это был бы просто один класс, такой как: 

private virtual Person Person { get; set; }

РЕДАКТИРОВАТЬ: Если вы не хотите реструктурировать всю базу данных, у вас может быть просто выпадающий список, который спрашивает, что это за возможность (клиент или проспект). В зависимости от выбора вы добавили бы внешний ключ в таблицу возможностей для ссылки на вашего [клиента или клиента].

...