Нужны ли порядковые номера?

Question

Я работаю над приложением winform (.NET), которое включает в себя заказы, счета-фактуры, сервисные заказы, оформление билетов и т. Д.

Нужно ли, чтобы эти сущности были последовательными при нумерации их идентификаторов? ИМО нет. Возьмите, например, заказ, он может быть действителен только после прохождения через бизнес-уровень, во время этого процесса мог быть создан, утвержден и сохранен другой заказ под номером 2, в то время как заказ, созданный ранее с идентификатором 1, не прошел проверку.

Это, кажется, открывает банку червей относительно того, какой слой назначает номер заказа, нет?

В настоящее время я использую непоследовательные числа с префиксом идентификатора для сущности. Пример, заказ использует OR-123. Это хорошая идея?

Спасибо

Связанный:

Уникальные, но простые идентификаторы для всей базы данных в SQL Server

Answer 1

У вас должны быть только последовательные идентификаторы, если это действительное требование бизнеса.

Answer 2

Последовательные числа не нужны, а в некоторых сценариях это плохая идея (в системах, обеспечивающих безопасность, где угадывание является проблемой). Но это довольно распространено, чтобы позволить СУБД справиться с этим - большинство поддерживают тип IDENTITY с автоинкрементом (хотя он становится более сложным с несколькими распределенными главными серверами). Другой вариант - это, конечно, Guid - мало шансов на дубликаты.

Префиксный подход довольно удобен для быстрой идентификации чисел, но вы можете просто добавить «ИЛИ» на слоях над БД.

Answer 3

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

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

Answer 4

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

Answer 5

По моему опыту с готовыми и сделанными на заказ системами бухгалтерского учета в США, бухгалтерам или аудиторам не требуются последовательные номера. Что требуется, так это демонстрация возможностей контроля и аудита. Если элемент удален, должен быть след. Обнаружение удаленного элемента не отслеживается по отсутствующему номеру - в конце концов, существуют другие виды вмешательства, требующие последовательных номеров, и демонстрация адекватного контроля выходит далеко за рамки этого.

Однако в Мексике я видел такое требование о возмещении расходов правительству. Я полагаю, что они используют это, чтобы избежать мошенничества для многократных представлений государственному агентству. ИМО, это не эффективный внутренний контроль, и он имеет ограниченные возможности для выявления мошенничества в ситуации взаимодействия со сторонними организациями.

Как правило, использование увеличивающегося целочисленного идентификатора (например, IDENTITY) (или GUID - но обычные идентификаторы GUID не увеличиваются таким образом) в качестве суррогатного первичного ключа в таблицах и кластеризации, что помогает повысить производительность SQL Server. Обратите внимание, что значение IDENTITY может быть использовано, но транзакция завершится неудачно или будет отменена, оставляя пробел. Этот пробел обычно не заполняется (хотя это может быть сделано с использованием идентификационной вставки).

Вот некоторые ссылки на COMB ID:

http://jeffreypalermo.com/blog/use-guid-comb-in-your-database-if-you-need-guid-keys-but-don-t-want-to-take-a-big-performance-hit/

http://www.informit.com/articles/article.aspx?p=25862

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

Answer 6

Если указанное поле является вашим первичным ключом, последовательные числа вводятся быстрее, даже если вы пропустите от 1 до 3 и т. Д.

Но последовательные числа создают проблему безопасности: люди «угадывают» URL-адреса, случайно переносят числа или раздают бизнес-данные (сколько у вас пользователей и т. Д.).

Один из вариантов - использовать GUID (тип уникального идентификатора). Это не удобно для людей, говорящих вслух или набирающих текст, но оно достаточно случайное и уникальное.

Если вы используете SQL Server 2005, новая функция SequentialID () вернет последовательный GUID, который даст вам необходимую уникальность и быструю вставку в таблицу.

Если вы решите использовать какой-либо случайный номер, я рекомендую вам также иметь в вашей таблице столбец smalldatetime по умолчанию GETDATE (), чтобы вы могли упорядочивать и фильтровать строки по дате создания.

Answer 7

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

Вы, пользователи, можете привыкнуть думать с точки зрения последовательных чисел. Может быть, сотрудники делают ставки на то, кто получит упаковку с номером заказа 10000? Возможно, они были бы очень расстроены, если бы кто-то сказал им, что ставки отменены из-за новой компьютерной системы.

Answer 8

Вы должны спросить своего делового контакта, действительно ли номера должны быть последовательными, а не мы.

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