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

Question

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

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

---

Принято Ответ

ответ Michael Haren в выбранном из-за большинство голосов до, но, пожалуйста, прочитайте другие ответы и комментарии, как они делают ответ Майкла более полным.

Answer 1

Пойдите со всеми цифрами или буквами. Если вы должны смешать его, убедитесь, что нет двусмысленных символов (Il1m, O0 и т. Д.).

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

Редактировать: Другая вещь, которую следует учитывать, имеет встроенный способ различать заказы, клиенты и т. Д., Например. клиенты всегда начинаются с 10, заказы всегда начинаются с 20, продавцы всегда начинаются с 30 и т. д.

Answer 2

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

Пример:

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

00000-00000-00000-00000 - число может быть заказом

Answer 3

Чтобы опираться на вопросы Даниила и Майкла: еще лучше, если отделенные номера ЗНАЧИТЕЛЬНО что-то еще. Например, я работал в компании, где номера счетов были, как это:

XXXXXXXX-XXXXXXXX

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

Answer 4

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

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

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

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

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

Answer 5

Я бы мои порядковые номера имеют следующий формат:

ddmmyyyy-####-#### 

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

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

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

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

Надеюсь, что это поможет!

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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

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

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

Answer 8

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

Answer 9

Придерживайтесь цифр (без символов или специальные вещи):

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

Answer 10

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

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

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

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

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

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

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

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

Предложенный формат так же просто, как это возможно, но не проще:

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

Примеры

• Предполагая:

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

Преимущества такого подхода:

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

Недостатки

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

Answer 11

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

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

Answer 12

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

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

Количество разрядов для каждого будет зависеть от ожидаемого объема. Вы всегда будете иметь большее количество номеров заказов, чем номера клиентов. Шестизначный номер клиента, начинающийся с 100000, по-прежнему даст вам 899999 клиентов. Добавьте дополнительные 3-4 цифры для номера заказа, вы получите от 999 до 9999 заказов на одного клиента (больше, если вы считаете одного из клиентов).

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

ПОЦЕЛУЙ (держать его просто StackOverflow)

Answer 13

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

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

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

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

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

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

Answer 14

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

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

Второй этап: Такие системы никогда не существуют в вакууме.Существует ли уже общеорганизационная схема для идентификаторов пользователей и/или заказов, например, в системе учета, управления запасами или CRM? Если это так, подумайте об использовании существующих схем для облегчения взаимодействия. Многие крупные организации имеют несколько способов указать одного клиента или заказ, и это просто делает получение полезного интеллекта из данных, которые намного сложнее.

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

Answer 15

Я бы никогда не использовать информацию о пользователе в идентификаторах. Предположим, вы используете первые буквы имени клиента, за которым следует некоторое число: например. Thomsom может быть заказчиком THOM-0001. Только, похоже, вы допустили ошибку, а имя человека - Томсон, а не Томсон. Пользовательские данные могут быть скорректированы, идентификаторы никогда не должны быть модифицируемыми. Итак, в следующий раз, когда вы подыщете Tomson под TOMS -..., вы не сможете его найти. То же самое с другими данными, например, с типом клиента. Он всегда может меняться, ID не может.
Это очень просто для РСУБД.

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

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

Answer 16

НЕ ОДОБРЕН encode ANY изменяемая информация о клиенте/заказе на номера! И вы должны предположить, что все изменчиво!

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

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

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

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

Не зная многое о компании, я бы начать по этому пути:

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

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

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

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

Answer 17

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

Я также иногда начинаю номер заказа, скажем, 6 цифр, начиная с 200 000 и номера клиентов на 5 цифр, начиная с 10 000, которые, например, дают мне 90 000 уникальных номеров клиентов и 800 000 уникальных номеров заказов, и вы могли бы всегда скажите, просто посмотрев на это, был ли это номер клиента или номер заказа. (т. е. если представитель клиента запрашивал номер по телефону, сразу было бы очевидно, что именно было)

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

Answer 18

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

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

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

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

После этого вы получите 8 цифр для фактических данных.

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

Answer 19

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

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

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

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

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

Answer 20

Самой большой проблемой здесь является попытка не переубедить проблему.

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

Для заказов целое число с автоматическим добавлением отлично работает как первичный ключ в базе данных, а также номер, который клиент увидит на его/ее счете. Нет абсолютно никаких оснований для создания сложного алгоритма для ваших номеров. Если вы хотите указать, в какой стране/регионе они используют отдельное поле в вашей базе данных. Также, если вас беспокоят ваши конкуренты, шпионящие за вами; позволь им! Если ваш бизнес вращается вокруг шпионажа на ваших конкурентов, потому что вы не получаете достаточный доход, скорее всего, ваш бизнес не очень хорош в первую очередь. Также, если вы хотите обмануть своего конкурента, вы можете просто создать свой собственный скрипт, который будет автоматически создавать поддельные заказы. Если ваша система электронной коммерции хорошо разработана, это не будет проблемой.

Key материал с помощью автоматического приращения целое:

• Все номера/цифры => проще общаться, никакой двусмысленности по телефону, не работает для всех языков/культур, которые используют 0-9 в качестве системы счисления
• Никакого дополнительного кодирования
• Выглядит красиво на счете, и это самое короткое количество цифр клиенту когда-либо нужно будет прописать по телефону
• работ для малого и крупного бизнеса
• Это масштабируемое
• Serviceminded/Customerminded (Что лучше для клиента) (SE пули 1 и 3)
• Простой

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

Answer 21

Для меня предпочтительна комбинация даты + счетчик для сегодняшней транзакции. Мне было предложено выбрать номер из 5 цифр. Так с этим, я пришел с ниже следующим образом:

1. Я должен получить текущую дату, то
2. получить текущий счетчик для сегодняшней сделки добавьте 1.

Я решил использовать счет больше десятичной (10), поэтому я использую базу 16 для подсчета. Таким образом, если я получу максимум 5 цифр из шестнадцатеричного (FFFFF), то это будет 1 048 575 пунктов. Объединяя дату, могу сказать, что могу получить 1 048 575 штук в день. Таким образом, чтобы сделать этот счетчик уникальным каждый день, я перепутал дату, получив сумму следующее:

• Текущий отсчет Год, начиная с года осуществления, который является 1
• Текущий час (макс 24)
• Текущий день года (максимум составляет 365)

Так с этим, я буду иметь максимум 3-х символов начала для моего счета. Так что это будет текущая транзакция XXX + Todays.Пример:

Текущая дата: Дата 2014-12-31 1:22 вечера Реализация: 2010 Запуск общей для сегодняшней сделки: 100

Количество: (5 + 13 + 365) + 101 = 383101 Номер заказа: AD-5D87D

AD есть только заказный префикс номера заказа. Таким образом, к тому времени, когда я буду не в порядке, который будет 1000000 лет с момента моей даты реализации.

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