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

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

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

В общем, использование увеличивающегося целочисленного идентификатора (например, 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 предоставляет свойство даты создания. К сожалению, я больше не связан с этим проектом или компанией, поэтому у меня нет доступа к исходному коду, чтобы точно вспомнить нашу технику.

Вам нужны только последовательные идентификаторы, если это допустимое бизнес-требование.

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

Подход с использованием префиксов очень удобен для быстрого определения чисел, но вы можете просто добавить «OR-» перед слоями выше db.

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

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

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

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

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

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

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

Один из вариантов - использовать GUID (тип uniqueidentifier). Говорить вслух или набирать текст не очень удобно для человека, но достаточно случайный и уникальный.

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

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

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

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