Каков лучший формат для клиентского числа, номера заказа?

Ничего себе - что простой все же разоблачающий вопрос! И что много противоречащих ответов. Я думаю, что здесь существует 3 очевидных ответа кандидата:

1) Использование длинное целое автопостепенного увеличения. 2) Используют GUID 3), Использование составной тип, который включает другую информацию в идентификатор.

Для более простых систем и особенно веб-систем, где все пользователи поражают центральную базу данных, (1) работы хорошо. Это имеет преимущество, что числа остаются максимально короткими и простыми, но не короче, избегает буквенных символов (Вы были бы поражены, насколько отличающийся названия тех же букв находятся в разных странах - страны E являются другим страны I). Это не дифференцирует ID заказа от идентификатора клиента внутренне, но Вы могли всегда предварительно ожидать или добавлять "C" или "O" каждому и тихо отбрасывать их на записи? Это также не имеет контрольной суммы или проверки на ошибки.

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

Что касается (3) - информация о регионе встраивания или сегодняшняя дата в число - это - виды идей, что опытные разработчики обучают себя из. Похож на хорошую идею сначала, но всегда заставляет Вас пожалеть. Рассмотрите случай, куда клиент перемещается в новое состояние, или порядок вручную повторно вводится спустя неделю, после того, как первоначально выпущено? Эти единицы информации принадлежат связанных таблиц, где они могут быть отредактированы независимо идентификатора, который должен представить идентификационные данные объектов только. Повторяться: НИКОГДА НЕ КОДИРУЙТЕ БИЗНЕС-ДАННЫЕ В идентификаторе AN ИЛИ PRIMARY KEY - каждый раз, когда Вы делаете это, Вы оставляете бомбу замедленного действия для других для чистки однажды.

, Учитывая, что это - централизованный (базирующийся телефон) система, я пошел бы с опцией (1), пока ясная потребность не возникла для изменения. Более простой обычно лучше. Вставьте дефисы, как другие предполагают и предварительно ожидают или постожидают контрольную сумму и/или определяющий букву при необходимости.

Дополнительное соображение к проблеме формата - в коде, создайте отдельный класс для OrderId и CustomerId. Эти классы неизменны, и проверяют свой вход, чтобы гарантировать, что они - приемлемые идентификаторы. Кроме того, никакое значение не могло быть и ID заказа и идентификатор клиента.

самый простой подход должен был бы просто иметь отступающие значения для OrderId быть ints, которые запускаются с 1, и CustomerIds быть ints, которые запускаются с 2, или что-то подобное.

Я предложил бы использовать 16 идентификаторов цифры, которые при печати или показе клиентам отформатированы в формате xxxx-xxxx-xxxx-xxxx, но сохранены как числа без тире в системе.

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

, При необходимости первые 4 цифры могут использоваться для идентификации типа числа, 1000 для клиентов, 2000 для поставщиков, 3000 для заказов, 4000 для счетов и т.д.

, второй набор может тогда идентификатором года/месяц, если бы Вы хотите сохранить такую информацию закодированной в самом числе, с помощью формата yymm, таким образом, 1000-0903-xxxx-xxxx был бы клиентом, вводимым в марш 2009.

Это тогда оставляет Вас с 8 цифрами для самих фактических данных.

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

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

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

количество цифр для каждого будет зависеть от Вашего ожидаемого объема. У Вас всегда будет большее количество Номеров заказа, чем Потребительские Числа. Шесть Потребительских чисел цифры, запускающихся в 100 000, все еще дадут Вам 899 999 клиентов. Добавьте еще 3-4 цифры для номера заказа, даст Вам 999 - 9 999 распоряжений на клиента (больше, если Вы рассмотрите один от клиентов).

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

KISS (сохраняют это простым stackoverflow)

Придерживайтесь чисел (никакие символы или специальный материал):

• Может быть легко введен в потоке IVR
• его международное - Никакие стычки языка
• Никакой беспорядок в символах по сравнению с числами - O по сравнению с 0, я по сравнению с 1
• , пока продвижение 0 бессмысленно, можно хранить/управлять их эффективнее

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

Пример:

000-00000-00000 - мог быть клиент номер

00000-00000-00000-00000 - мог быть номер заказа

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

2. целые числа Автопостепенного увеличения - все хорошо и хороший для компьютеров, но они значительно уменьшают способность людей определить ошибки. Как важный, который является, будет зависеть от Вашего бизнеса. Я работаю со свойством, связанным с (корпусом) данным и нашей основной ссылке встроили парадную дверь в него. Это не изящно, но это означает, что опытный администраторский коллектив может определить 90% незначительных ошибок (когда мы получаем счета, и т.д. в), прежде чем они доберутся около базы данных. Но в среде, где Вы не полагаетесь на такой процесс, этот аргумент менее востребован.

(Теперь, некоторые люди сильно предупредили об использовании значимых данных в ссылках, поскольку это могло быть изменено, и существует некоторая истина в этом, но можно быть умными. Вы не должны выбирать что-то очевидно непостоянное как то, женат ли человек - можно привязать себя на прошедших событиях как символ, представляющий регион, они сначала открыли конкретную учетную запись. Даже если Вы не делаете этого, имейте некоторый шаблон для помощи связи с клиентами. Я работал во многих центрах обработки вызовов, и люди иногда приезжают для вызова по телефону с каждой частью документации из свидетельства о рождении вперед, поскольку они отчаянно пытаются найти свое число учетной записи/порядка/клиента. Я не думаю, говоря, что "Это будет число между 1, и 100 триллионов" были бы очень удобны)

3. , Это было сказано, но не создает чрезвычайно дальние ссылки. Мы - занятые люди, у нас нет времени, чтобы ввести это дерьмо по телефонной системе и сделать ошибку на цифре 17 только для перезапуска (снова). У некоторых Ваших клиентов могут быть нарушения, и вероятно, что растущее число будет более чем 55 +. Еще раз не упустите обнуление. Вы видите числа заказа на покупку и т.п. с четырнадцатью цифрами. Сколько заказов они думают, что собираются быть размещением?

4. , Если там будет каким-либо агрегированием данных за пределами Вашей сети (и таким образом не подключенный к Вашей базе данных) - имеют своего рода контрольный разряд / образец регулярного выражения, который Ваши партнеры/поставщики могут проверить, что они не сделали ошибки. Одним примером этого является система нумерации электропитания Великобритании (MPAN), хороший пример этого - разработанный, чтобы люди поддержали свои собственные записи, не имея необходимость загружать большой список каждого метра электричества во вселенной, чтобы проверить, что они не сделали опечатку.

предположение, что создание заказов/клиентов не централизовано или будет не всегда централизоваться, использует GUID

, если бы создание заказов/клиентов будет всегда централизоваться, целое число без знака было бы прекрасно

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

РЕДАКТИРОВАНИЕ: для MOTO любой мультисимвольный алфавитный идентификатор вызовет проблемы по телефону, таким образом, GUID будут правильными. Принятие несколько децентрализовали местоположения MOTO, присваивают каждому местоположению MOTO префикс (A, B, C, и т.д., или 01, 02...) и используют целое число, или большое целое число для клиента и ID заказа, например, 01-1 является первым порядком от местоположения MOTO № 1. Обратите внимание, что дополнение нуля является ненужным, накладывает неявное ограничение цифры к числам и требует, чтобы клиент различал шесть нулей и семь нулей при разговоре числа. Если необходимо использовать заполненный формат фиксированной длины, разбить число в группы из не больше, чем 4 или 5 цифр каждый.

ПРИЛОЖЕНИЕ: номер заказа и потребительское число не должны быть первичными ключами их соответствующих таблиц, просто уникальные индексированные столбцы для поиска. Вы, вероятно, захотите использовать что-то более простое/больше, эффективное для первичных ключей в базе данных.

У меня были бы свои номера заказа, следуют за этим форматом:

ddmmyyyy-####-####

, Где ####-#### обнуляет в начале каждого дня. Это делает очень легким коррелировать заказы с датой, это было помещено.

Для идентификаторов клиентов, я смешал бы прописные буквы и числа, но поскольку Michael сказал, избегают обычно ошибочных букв (0, o, L, 1,5, s). Это даст Вам 30 символов для контакта с. Если Вы используете 20 символов, которые дадут Вам почти диапазон на 64 бита идентификаторов клиентов - довольно хороший для безопасности. Удостоверьтесь, что Вы используете безопасный генератор случайных чисел при генерации идентификатора. Что касается того, как Вы отображаете формат, это должно быть следующим:

####-####-####-####-####

, Поскольку Michael повторил, удостоверьтесь, что Ваша система может иметь дело с тире, пробелами, никакими пробелами или никакими тире. (Это должно просто разделить все те символы от входа перед проверкой.)

я надеюсь, что это помогает!

Я был бы никогда информация о пользователе использования в идентификаторах. Предположим, что Вы используете первые буквы фамилии клиента, сопровождаемой некоторым числом: например, Thomsom мог быть клиентом ТОМОМ 0001. Только, кажется, что Вы сделали ошибку, и именем человека является Tomson вместо Thomson. Пользовательские данные могут быть исправлены, идентификаторы никогда не должны быть модифицируемыми. В таким образом, следующий раз Вы ищете Tomson под TOMS-... Вы не можете найти его. То же с другими данными, как потребительский тип. Это может всегда изменяться, идентификатор не может.
Это является очень простым к RDBMS.

Просто целые числа использования. Для удобочитаемости это - хорошая идея вставить разделители, таким образом, что у Вас никогда нет больше чем 4 последовательных цифр: 9999-9999 лучше, чем 999-99999. И не делайте число дольше, чем необходимый; люди намного более раздражаются, будучи уменьшенным до 20 чисел цифры, чем просто быть уменьшенным до числа.

существует выгода, все же. Особенно, если бы у Вас есть малый бизнес, простые счетчики могут дать более далеко, чем Вы ценили бы. Скажите, что я заказываю что-то от Вас, и номер заказа 090145. В следующем месяце я заказываю снова, и номер заказа 090171. Er.. 26 заказов за месяц? То же, я не чувствовал бы себя комфортно для становления клиентом 0006 в бизнесе, который был активен в течение 10 лет.
решение просто: пропустите числа. Не используйте случайные числа, потому что Вы все еще хотите, чтобы они были в последовательности.

• Делают число настолько же долго по мере необходимости, но больше. Каждый раз, когда я оплачиваю свой водный счет, я должен ввести свой 20-разрядный потребительский номер и 18-разрядный номер счета-фактуры. К счастью тире в моем потребительском числе разделяет его на две части.

• не зависят от начальных нулей. Необходимость выяснить, сколько нулей находится в моем номере счета-фактуры, является чрезвычайно раздражающей. Возьмите 000000000051415432, например. Их система не распознает всего 51415432.

• цифры Группы вместе . Если абсолютно необходимо использовать длинные числа, четырехразрядные блоки должны работать хорошо.

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

Предположения на основе того, что это - международная организация:

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

Предположения на основе того, что существует две таблицы, для которых будет использоваться этот формат:

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

Соображения:

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

Предложенный формат: SSSS0RR0TTC

предложенный формат максимально прост, но не более прост:

• C первый (самый правый) символ будет контрольной суммой всех других символов в идентификаторе. Простая контрольная сумма сделает. Это устранит 90% всех опечаток. Если решено, чтобы это было недостаточно, то это может быть расширено до 2 цифр, которые устранят 99% всех опечаток.
• TT следующие цифры N представляют число типа таблицы. Никакое число типа таблицы не может содержать нуль цифры.
• следующая цифра является нулем. Этот нуль разделяет число типа таблицы от номера региона.
• RR следующие цифры N являются номером региона. Никакие цифры региона не могут содержать нуль.
• следующая цифра является нулем. Этот нуль разделяет регион от порядкового номера.
• SSSS следующие цифры N являются порядковым номером. Это число может содержать нули.
• Каждый набор четырех чисел разделяется пробелами при печати или вводе условно. Внутренне они не разделяются, но это помогает пользователю передать их правильно.

Примеры

• Принятие:

  • Код региона таблицы type=2
  • таблицы Order таблицы type=1
  Customer для кода региона US-Alabama=1
  • для кода региона CA-Alberta=43
  • для Ethopia=924
• 10 1013 - Клиент № 1 в Алабаме (3 контрольная сумма: 1 +1 + 1)
• 10 1024 - Порядок № 1 в Алабаме
• 9259 0304 3016 - клиент № 925903 в Альберте, Канада
• 20 3043 4092 4023 - номер заказа 2030434 в Преимуществах Ethopia

этого подхода:

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

Недостатки

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

Основываться на Daniel и вопросах Michael: еще лучше, если разделенные числа ОЗНАЧАЮТ что-то еще. Например, я работал на компанию, где номера аккаунта были похожи на это:

xxxx-xxxx-xxxxxxxx

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

Основное преимущество использования только нумерует, то, что они могут быть введены намного более эффективно с помощью с 10 ключами.

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

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

, Например, 323-23-5344, то, которое, конечно, является форматом номера социального страхования, помогает сообщить докладчику, где приостановиться при напевании числа. Это также обеспечивает визуальное формирование рисунка при записи числа и помогает выдержать сравнение при копировании числа.

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

я не соглашаюсь, так слишком много информации должно быть встроено в это число особенно, если те атрибуты могли бы измениться. Например, скажите, что мы даем "323", значение "является хорошим клиентом", но тогда они звонят в четыре раза с отношением. Мы тогда собираемся изменить их потребительский ключ к "324", "толчок"? Что, если они находятся в регионе 04 и перемещают свою компанию в регион 05?

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

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

не ДЕЛАЮТ , кодируют ЛЮБОЙ изменяемый клиент/информация для заказа в числа! И необходимо предположить, что все изменяемо!

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

Клиент/информация для заказа принадлежит записи клиента/порядка. Не в идентификаторе. можно изменить запись клиента/порядка позже. Идентификаторы обычно пишутся в камне.

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

больше чем одна система будет генерировать эти числа? Если так, у Вас есть потенциал для дублирования при использовании только основанных на дате и/или порядковых номеров.

, не зная очень о компании, я запустил бы вниз этот путь:

• один код символа А идентификация типа числа. C для клиентов, R для заказов (не используют "O", поскольку он мог быть перепутан с нулем), и т.д.
• идентификатор системы, которая генерировала число. Длина этого идентификатора зависит от сколько из этих систем будет.
• порядковый номер А, уникальный для системы, генерирующей его. Просто счетчик.
• случайное число А, для предотвращения отгадываемых чисел порядка/клиента. Сделайте это, пока Ваша паранойя требует.
• А простая контрольная сумма. Не для безопасности, а для проверки ошибок.

Разбивание это в сегменты делает это более человекочитаемым, как указали другие.

CX5-0000758-82314-12 является возможным числом, сгенерированным этим подходом. Это состоит из:

• C: это - потребительское число.
• X5: станция, которая генерировала число.
• 0000758: это - 758-е число, сгенерированное X5. Мы можем генерировать 10 миллионов прежде, чем ликвидировать этот идентификатор станции или саму станцию. Или не дополняйте нулями и нет никакого предела.
• 82314: это было случайным образом сгенерировано и результаты в 1/100,000 шансе предположения идентификатора клиента.
• 12: контрольная сумма.

Можно добавить, что небольшая контрольная сумма (использующий XOR, например) для обеспечения (улучшает) правильность данных идентификаторов. Если это почтой, рассмотрите кодирование z-base-32. Но здесь, с телефонными заказами, можно предпочесть десятичную идентификацию.