Как правильно определить плохо определенные объекты?

Question

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

Таблица SpecialCode varchar (10)Описание варчар (50) (ПК)некоторое значение int

Первоначально SpecialCode мог быть null.Но было бы полезно иметь SpecialCode как часть первичного ключа с описанием.Теперь описание больше не является уникальным.Итак, я пошел дальше и сделал SpecialCode частью ключа и присвоил ему какое-то поддельное значение по умолчанию.

Конечно, фиктивное значение теперь необходимо будет учитывать для дальнейшего развития конвейера обработки.

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

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

Answer 1

Люди так же настойчиво утверждают, что суррогатные идентификаторы часто являются лучшим дизайном. Я нахожу, что естественные ключи часто не являются действительно уникальными, даже если вы думаете, что они будут, и если они есть, они изменяются так часто, что вызывают много дополнительной работы с БД, чтобы поддерживать их в дочерних таблицах. Плюс объединения быстрее с целыми числами (хотя некоторые натуральные ключи могут позволить вам избежать некоторых объединений). Это может сильно зависеть от типа данных, которые вы обычно видите, но я настоятельно предпочитаю суррогатные ключи с уникальными индексами естественного ключа, если он существует.

Answer 2

Вы все еще можете добавить ключ Identity Seed в эту таблицу.Это не повредит существующему коду и позволит вам модернизировать код.

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

spAddDescription   (original)
spAddDescription01 (revision 1)
spAddDescription02 (revision 2)

spUpdateDescription   (original)
spUpdateDescription01 (revision 1)
spUpdateDescription02 (revision 2)

Это позволяет мне работать в производственном режиме, но все же позволяет медленно интегрировать модификации.Как правило, чем выше номер редакции, это означает, что были включены самые последние изменения.