Действительно ли порядковые номера необходимы?
Я полностью согласен с Питером Гвиаздой, поэтому я не могу больше рассказать об этом разделе, так как он охватил их все. То, что я хочу добавить, это некоторые другие характеристики. Прежде всего, подумайте, чего вы хотите достичь. Какое приложение вы хотите разработать? Также поиск в том, что вы хотите, чтобы это приложение для запуска. Затем вы решите, какой тип языка / структуры вы хотите разработать для приложения. Очистите свою цель, проанализируйте, какие рамки будет лучше разрабатывать (основываясь на спросе, на мой взгляд), а затем идите и изучайте. Вы не можете выучить их всех сразу! У каждого языка / платформы есть свои плюсы и минусы, поэтому вы сами решите, что вам больше подходит!
8 ответов
По моему опыту работы с стандартными и заказными системами бухгалтерского учета в США, бухгалтеры или аудиторы не требуют порядковых номеров. Что требуется, так это демонстрация возможностей контроля и аудита. Если элемент удален, должен быть след. Обнаружение удаленного элемента не отслеживается по отсутствующему номеру - в конце концов, существуют и другие виды взлома, чтобы обойтись без последовательных номеров, и демонстрация адекватного контроля выходит далеко за рамки этого.
Однако я видел такие требование в Мексике о возмещении расходов от правительства. Я считаю, что они используют это, чтобы избежать мошенничества при многократном обращении в государственный орган. ИМО, это не эффективный внутренний контроль, и у него ограниченные возможности для выявления мошенничества в ситуации взаимодействия с третьими сторонами.
В целом, использование увеличивающегося целочисленного идентификатора (например, IDENTITY) (или GUID - но обычные идентификаторы GUID не увеличиваются таким образом) в качестве суррогатного первичного ключа в таблицах и кластеризации, что помогает повысить производительность SQL Server. Обратите внимание, что значение IDENTITY может быть израсходовано, но транзакция завершится неудачно или откатится, оставив пробел. Обычно этот пробел не заполняется (хотя это можно сделать с помощью вставки идентификатора).
Вот несколько ссылок на COMB ID:
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, который дает вам обоим уникальность. вам нужна и быстрая вставка в вашу таблицу.
Если вы решите использовать какое-то случайное число,
Вам следует спросить своего делового представителя, действительно ли номера действительно должны быть последовательными, а не мы.
И сказать тому же деловому человеку, что в большинстве случаев это практически невозможно. чтобы компьютерная система давала водонепроницаемые гарантии по этому поводу.