Есть ли причина для использования некластеризованного идентификатора NVARCHAR 36 с одновременным увеличением PK SerialID? - PullRequest
0 голосов
/ 25 октября 2019

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

Это недавно купленная ERP-платформа моей компании. он разработан, чтобы иметь NVARCHAR (36) ParentID и RecordID для каждой строки и в основном использовать его повсюду. Он имеет числовой инкрементальный PK в то же время.

, когда я запускаю свои тесты запросов, особенно там, где мне нужно объединить таблицы, или когда должен быть родитель с 2 ~ 3 дочерними таблицами, этот NVARCHAR (36)неуникальные некластеризованные индексы RecordID просто очень меня беспокоят.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...