Почему наборы полей для адресов учетных записей содержатся в таблице учетных записей, а не в отдельной таблице?

Просматривая документацию Microsoft по Common Data Model и Microsoft Dataverse, а также сам Powerapps, я обнаружил содержимое таблицы Account. Эта таблица содержит два набора адресных полей. Документация Microsoft предполагает, что один из них является основным адресом, а второй может быть альтернативным адресом, например, для выставления счетов.

Документация:

Разве таблица Account не должна содержать только основную информацию об Account, а в отдельной таблице, связанной с Account, не должны ли мы содержать адреса, связанные с Account, и связывать эти две записи отношениями родитель-потомок?

Сможет ли кто-нибудь объяснить мне, что стоит за этим подходом?

2 ответа

Общая модель данных происходит от исходных объектов (теперь называемых таблицами), определенных в Dynamics CRM. Описанная здесь модель не является «нормализованной» с точки зрения базы данных (Dynamics CRM, теперь называемый Dataverse, использует SQL Server под капотом), поэтому, как вы обнаружили, у вас есть поля адресов (теперь называемые столбцами) внутри учетной записи.

Имейте в виду, что общая модель данных - это один из возможных подходов, вы можете, например, создать настраиваемую таблицу для хранения адресов и связать ее с учетной записью или создать настраиваемые таблицы для хранения учетных записей и адресов.

Отказ от ответственности: у меня нет конкретного опыта в динамике, поэтому есть вероятность, что я ошибаюсь в своей интерпретации.

Ни в одной из ссылок, которыми вы поделились, не упоминается слово «таблица» и не предлагается реляционная модель данных.

Я считаю, что эти ссылки описывают формат / схему, но ничего конкретно не говорят о том, как хранятся базовые данные.

Поэтому, если вы хотите использовать СУБД и сохранить рабочий / почтовый адрес в таблице адресов, я не думаю, что здесь есть что-то, что предполагает, что вы не можете этого сделать.

Другие вопросы по тегам