Крупная международная компания внедряет новую систему управления сайтом и MOTO (Mail Order and Telephone Order). Помимо прочего, вам поручено разработать формат как для номеров заказов, так и для клиентов.
Какой был бы лучший формат, на ваш взгляд? Просьба перечислить любые предположения и соображения.
Принятый ответ
Майкл Харен отвечает выбранным из-за самых высоких голосов, но, пожалуйста, прочитайте другие ответы и комментарии, поскольку они заставят Майкла ответить более полным.
Перейдите со всеми числами или всеми буквами. Если вы должны смешать его, убедитесь, что нет двусмысленных символов (Il1m, O0 и т.д.).
При отображении/печати помещайте пробелы в каждые 3-4 символа, но убедитесь, что ваши системы могут обрабатывать входы без пробелов.
Изменить: Еще одна вещь, которую следует учитывать, - иметь встроенный способ различать заказы, клиенты и т.д., Например. клиенты всегда начинаются с 10, заказы всегда начинаются с 20, поставщики всегда начинаются с 30 и т.д.
НЕ закодировать ЛЮБОЙ изменяемый клиент/информацию о заказе на номера! И вы должны предположить, что все изменено!
Некоторые из приведенных выше предложений включают код региона. Компании могут двигаться. Ваша собственная компания может реорганизовать и изменить собственное определение регионов. Имена клиентов/компаний могут также измениться.
Информация о клиенте/заказе принадлежит записи клиента/заказа. Не в идентификаторе. Вы можете изменить запись клиента/заказа позже. Идентификаторы обычно написаны на камне.
Даже просто кодирование даты, в которой номер был сгенерирован в ID, может показаться безопасным, но предполагается, что дата никогда не ошибается в системах, генерирующих числа. Опять же, это принадлежит записи. В противном случае он никогда не может быть исправлен.
Будет ли более чем одна система генерировать эти числа? Если это так, у вас есть потенциал для дублирования, если вы используете только даты и/или последовательные номера.
Не зная о компании, , я бы начал использовать этот путь:
Разбивание этого сегмента на сегменты делает его более понятным для человека, как указывали другие.
CX5-0000758-82314-12 - это возможное число, порожденное этим подходом , Это состоит из:
Основным преимуществом использования только чисел является то, что их можно вводить гораздо эффективнее с помощью 10-клавишного.
Длина этого числа должна быть как можно короче, оставаясь при этом охватывающей все пространство сущности, которое вы ожидаете от каталога с запасными местами. Это может быть сложно, и ему следует немного подумать. Немного теория множеств может дать вам количество уникальных ключей, к которым вы будете иметь доступ, учитывая группу элементов.
Естественно, говоря, разбивать числа на множества от двух до четырех цифр. Вставляя тире в какой-либо шаблон, вы можете "заставить" клиента повторить их более эффективным и недвусмысленным образом.
Например, 323-23-5344, который, конечно же, является номером формата социального обеспечения, помогает информировать говорящего о том, где пауза при озвучивании номера. Он также обеспечивает визуальное разграничение при записи номера и позволяет легко сравнивать при копировании номера.
Во-вторых, рекомендация о том, что система заказов правильно маскирует вход, чтобы в любое время не вводить тире. Это должно быть перенесено на печатные формы, чтобы обеспечить ясное ожидание того, что следует вводить. Например, печатный ящик для каждой цифры, разделенный печатными тире.
Я не согласен с тем, что в это число должно быть включено слишком много информации, особенно если эти атрибуты могут измениться. Например, скажем, мы даем "323" значение "хороший клиент", но затем они звонят в четыре раза с отношением. Пойдем ли мы сменить свой ключ клиента на "324", "это рывок"? Что делать, если они находятся в регионе 04 и перемещают свою компанию в регион 05?
Если это произойдет, ваши варианты будут состоять в том, чтобы обновить этот первичный ключ по всей базе данных или жить с неопределенностью, что информация, встроенная в этот ключ, перестает быть надежной, тем самым предоставляя всю информацию, встроенную в ключи сомнительной утилиты.
Лучше хранить атрибуты, которые могут изменяться как отдельные поля в базе данных, и иметь номер клиента, который является уникальным неизменным ключом для этого клиента.
Опираясь на вопросы Даниэля и Майкла: это даже лучше, если отделенные номера ОЗНАЧАЮТ что-то еще. Например, я работал в компании, где номера учетных записей были такими:
XXXXXXXX-XXXXXXXX
Первый набор чисел представлял регион, а второй набор представлял рынок в этом регионе. После того, как вы привыкли знать, что номера были из стали, он сделал это очень легко сказать, что площадь счет был даже без необходимости смотреть на счете клиента.
Есть несколько предположений, которые я делаю, отвечая на этот вопрос; некоторые из них основаны на том, что это крупная международная организация, а некоторые из них основаны на том, что формат предназначен для двух отдельных типов таблиц.
Предположения, основанные на том, что это международная организация:
Предположения, основанные на том, что существуют две таблицы, для которых этот формат будет использоваться:
Вопросы:
Предлагаемый формат: SSSS0RR0TTC
Предлагаемый формат настолько прост, насколько это возможно, но не проще:
<сильные > Примеры
Если предположить:
Преимущества такого подхода:
Недостатки
Сделать число до тех пор, пока это необходимо, но не больше. Каждый раз, когда я оплачиваю свой счет за воду, я должен ввести свой 20-значный номер клиента и 18-значный номер номер счета. К счастью, тире в моем номере клиента разделяет его на две части.
Не зависеть от начальных нулей. Чтобы выяснить, сколько нулей в моем номере счета очень раздражает. Например, возьмите 000000000051415432. Их система не будет распознавать только 51415432.
Группировать цифры вместе. Если вам абсолютно необходимо использовать длинные цифры, четырехзначные куски должны хорошо работать.
Я бы никогда не использовал информацию о пользователях в идентификаторах. Предположим, вы используете первые буквы имени клиента, за которым следует некоторое число: например. Thomsom может быть заказчиком THOM-0001.
Только, кажется, вы допустили ошибку, а имя человека - Томсон, а не Томсон. Пользовательские данные могут быть скорректированы, идентификаторы никогда не должны быть модифицируемыми. Итак, в следующий раз, когда вы подыщете Tomson под TOMS -..., вы не сможете его найти. То же самое с другими данными, например, с типом клиента. Он всегда может меняться, ID не может.
Это очень важно для РСУБД.
Просто используйте счетные числа. Для удобства чтения рекомендуется вставить разделители таким образом, чтобы у вас никогда не было более четырех последовательных цифр: 9999-9999 лучше, чем 999-99999. И не делайте число дольше, чем необходимо; люди гораздо более раздражены тем, что их уменьшают до 20-значного числа, чем просто уменьшаются до числа.
Там есть уловка. Особенно, если у вас есть небольшой бизнес, простые счетчики могут дать больше, чем вы бы оценили. Скажем, я что-то заказываю от вас, а номер заказа - 090145. В следующем месяце я закажу еще раз, а номер заказа - 090171. Er.. 26 заказов в месяц? То же самое, я бы не чувствовал себя комфортно, чтобы стать клиентом 0006 в бизнесе, который был активным в течение 10 лет.
Решение прост: пропустить числа. Не используйте случайные числа, потому что вы все еще хотите, чтобы они были в последовательности.
Я хотел бы, чтобы мои номера заказов соответствовали этому формату:
ddmmyyyy-####-####
Где #### - #### сбрасывается на ноль в начале каждого дня. Это упрощает сопоставление заказов с датой его размещения.
Для идентификаторов клиентов, я бы смешал заглавные буквы и цифры, но, как сказал Майкл, избегайте обычно ошибочных букв (0, o, L, 1,5, s). Это даст вам 30 персонажей. Если вы используете 20 символов, это даст вам почти 64-битный диапазон идентификаторов клиентов - довольно хорошо для безопасности. Убедитесь, что при генерации идентификатора вы используете защищенный генератор случайных чисел. Что касается отображения формата, это должно быть следующее:
####-####-####-####-####
Как снова сказал Майкл, убедитесь, что ваша система имеет дело с тире, пробелами, пробелами или тире. (Перед проверкой следует просто скрыть все эти символы от ввода.)
Я надеюсь, что это поможет!
Вы можете добавить небольшую контрольную сумму (например, с помощью XOR), чтобы обеспечить (улучшить) правильность заданных идентификаторов. Если он по почте, рассмотрите кодировку z-base-32. Но здесь, с телефонными заказами, вы можете предпочесть десятичную идентификацию.
предполагая, что создание заказов/клиентов не централизовано или не всегда будет централизованным, используйте GUID
если создание заказов/клиентов всегда будет централизовано, целое число без знака будет в порядке
нет убедительной причины, чтобы номер заказа номера клиента "имел в виду" что угодно, и вполне вероятно, что какая-либо схема с вычисленным сегментированным номером должна быть переделана по дороге. Придерживайтесь чего-то уникального и бессмысленного.
EDIT: для MOTO любой многосимвольный алфавитный идентификатор вызовет проблемы по телефону, поэтому GUID будут правы. Предполагая несколько децентрализованных местоположений MOTO, назначьте каждому местоположению MOTO префикс (A, B, C и т.д. Или 01, 02,...) и используйте целое или большое целое для идентификаторов клиента и заказа, например. 01-1 - первый заказ из местоположения MOTO №1. Обратите внимание, что нулевое заполнение не нужно, налагает неявное ограничение числа на цифры и требует от клиента различать шесть нулей и семь нулей при произнесении номера. Если вы должны использовать заполненный формат фиксированной длины, разбивайте номер на группы не более чем на 4 или 5 цифр.
ДОБАВЛЕНИЕ: номер заказа и номер клиента не должны быть первичными ключами их соответствующих таблиц, а просто уникальными индексированными столбцами для поиска. Вероятно, вы захотите использовать что-то более простое/более эффективное для первичных ключей в базе данных.
Мы используем ведущие нули для некоторых наших ссылок "числа", в которых я работаю, и я не могу сказать вам, сколько потраченных впустую часов у меня было за последние семь лет, заставляя Excel обрабатывать их как текст. Не делайте этого.
Автоматически увеличивающиеся целые числа хорошо подходят для компьютеров, но они значительно уменьшают способность людей обнаруживать ошибки. Насколько важно это будет зависеть от вашего бизнеса. Я работаю с данными о собственности (жилье), и наша основная ссылка имеет входную дверь, встроенную в нее. Это не изящно, но это означает, что опытный администратор может обнаружить 90% мелких ошибок (когда мы получаем счета и т.д.), Прежде чем они приблизится к базе данных. Но в среде, где вы не полагаетесь на такой процесс, этот аргумент менее убедителен.
(Теперь некоторые люди настоятельно предупреждают об использовании значимых данных в ссылках, поскольку они могут быть изменены, и в этом есть какая-то правда, но вы можете быть умными. Вам не нужно выбирать что-то явно непостоянное, как ли человек женат - вы можете привязать себя к прошлым событиям, например, к персонажу, представляющему регион, в котором они впервые открыли конкретную учетную запись. Даже если вы этого не сделаете, у вас есть какой-то шаблон, который поможет общаться с клиентами. колл-центров, а люди иногда звонят со всеми документами из свидетельства о рождении, так как они отчаянно пытаются найти номер своего счета/заказа/клиента. Я не думаю, что говорю: "Это будет число от 1 до 100 триллионов" было бы очень удобно"
Было сказано, но не создавайте чрезвычайно длинные ссылки. Мы заняты людьми, у нас нет времени на то, чтобы вводить эту дерьмо в телефонную систему и совершать ошибку на цифре 17 только для перезапуска (снова). Некоторые из ваших клиентов могут иметь инвалидность, и, вероятно, растущее число будет более 55+. Еще раз обратите внимание на нули. Вы видите номера заказа на поставку и т.д. Четырьмя цифрами. Сколько заказов они думают, что они собираются разместить?
Если будет какая-либо агрегация данных за пределами вашей сети (и, следовательно, она не подключена к вашей базе данных), у вас есть своего рода контрольная цифра/шаблон регулярного выражения, которые ваши партнеры/поставщики могут подтвердить, что они не сделали ошибки. Одним из примеров этого является система нумерации электроснабжения Великобритании (MPAN) - хороший пример этого - предназначен для людей, чтобы вести свои собственные записи, не загружая большой список каждого счетчика электроэнергии во вселенной, чтобы проверить, что они не сделали опечатка.
Я бы использовал цифры только потому, что это международная компания. Я бы использовал пробелы или тире каждые 4-6 чисел, чтобы разделить его. Я бы также сохранил формат для быстрой идентификации
Пример:
000-00000-00000 - может быть номер клиента
00000-00000-00000-00000 - может быть номер заказа
Придерживайтесь цифр (нет символов или специальных материалов):
Я бы использовал полностью числовые системы как для номера заказа, так и для номера клиента, это позволит вам избежать проблем с другими языками.
Избегайте ведущих нулей, так как это может вызвать проблемы с вводом и проверкой данных.
Количество цифр для каждого будет зависеть от вашего ожидаемого объема. Вы всегда будете иметь большее количество номеров заказов, чем номера клиентов. Шестизначный номер клиента, начинающийся с 100000, по-прежнему даст вам 899999 клиентов. Добавьте дополнительные 3-4 цифры для номера заказа, вы получите от 999 до 9999 заказов на одного клиента (больше, если вы считаете одного из клиентов).
Нет необходимости создавать какой-либо идентификатор в вашей последовательности нумерации. У вас есть другие поля базы данных, чтобы определить, где находится клиент, и т.д. Не слишком усложняйте свою систему.
KISS (сохраняйте его простым стеком)
Я бы предложил использовать 16-значные идентификаторы, которые при печати или показанных клиентам форматируются в формате xxxx-xxxx-xxxx-xxxx, но сохраняются в виде цифр без тире в вашей системе.
Причиной использования этого формата является то, что пользователям легче читать номер телефона, чтобы читать, поскольку они могут делать это партиями 4, а затем пытаются запомнить, сколько они уже сказали.
Если вы хотите, чтобы первые 4 цифры могли использоваться для идентификации типа номера, 1000 для клиентов, 2000 для поставщиков, 3000 для заказов, 4000 для счетов и т.д.
Второй набор может быть затем идентификатором года/месяца, если вы хотите сохранить такую информацию, закодированную в самом номере, используя формат yymm, поэтому 1000-0903-xxxx-xxxx будет клиентом, введенным в марте 2009 года.
После этого вы получите 8 цифр для самих фактических данных.
Я бы подумал о том, что использование букв в идентификаторах будет очень плохой идеей для любой системы, которая имеет дело с телефонами, поскольку различия в акцентах и понимание настолько разнообразны, что люди вынуждены расстраиваться при попытке распознать свой идентификатор тем, кто не может правильно понять их акцент.
Дополнительное внимание к выпуску формата - в коде, создайте отдельный класс для OrderId и CustomerId. Эти классы являются неизменными и подтверждают их ввод, чтобы гарантировать, что они являются приемлемыми идентификаторами. Кроме того, никакое значение не может быть и идентификатор заказа и идентификатор клиента.
Простейшим подходом было бы просто иметь значения поддержки для OrderId, которые начинаются с 1, а CustomerIds - int, которые начинаются с 2 или что-то подобное.
Вау - какой простой, но раскрывающий вопрос! И что много противоречивых ответов. Я думаю, что здесь есть 3 очевидных ответа на вопрос:
1) Используйте автоинкрементное длинное целое число. 2) Используйте GUID 3) Используйте сложный тип, который содержит другую информацию в ID.
Для более простых систем и особенно сетевых систем, где все пользователи попадают в центральную базу данных, (1) работает хорошо. Преимущество состоит в том, что числа остаются максимально короткими и простыми, но не короче, избегают буквенных символов (вы были бы удивлены тому, как разные имена для одних и тех же букв находятся в разных странах - одна страна E - это другие страны I). Он не отличает идентификатор заказа от идентификатора клиента по существу, но вы всегда можете добавить или добавить "C" или "O" к каждому и тихо отбросить их при записи? Он также не имеет контрольной суммы или проверки ошибок.
Для распределенных систем, где многие программные компоненты должны создавать числа "на лету", без ссылки на основную базу данных (2) - это единственный способ. У них есть преимущество в том, что они в основном проверяют ошибки, поскольку адресное пространство настолько велико, но, тем не менее, слишком длинное и буквенно-цифровое, чтобы удобно читать по телефону.
Что касается (3) - вложения информации о регионе или сегодня даты в число - это те идеи, которые опытные разработчики тренируются. Поначалу кажется хорошей идеей, но всегда возвращается, чтобы преследовать вас. Рассмотрим случай, когда клиент переходит в новое состояние, или заказ вручную открывается через неделю после того, как он был первоначально выпущен? Эти элементы информации принадлежат связанным таблицам, где они могут независимо редактироваться от идентификатора, который должен представлять только идентификатор сущностей. Повторить: НИКОГДА НЕ ОБОЗНАЙТЕ БИЗНЕС-ДАННЫЕ В ИДЕНТИФИКАЦИИ ИЛИ ПЕРВИЧНОМ КЛЮЧЕ - каждый раз, когда вы делаете это, вы оставляете бомбу замедленного действия для других, чтобы очистить один день.
Учитывая, что это централизованная (основанная на телефоне) система, я бы пошел с опцией (1), пока не возникнет явная потребность в изменении. Упрощение обычно лучше. Вставьте дефисы, как предлагают другие, и при необходимости добавьте или отложите контрольную сумму и/или идентифицирующую букву.
Первый шаг: в достаточно большой организации, требующей такой системы, существует существующая система, которую вы заменяете. Продолжайте предыдущую схему системы, если это возможно. Это облегчает многое, если вы можете получить доступ даже на базовом уровне к данным старой системы.
Тем не менее, часто есть веская причина для изменения схемы, особенно когда она исходит из унаследованной системы. я считаю, однако, что часто полезно официально исключить старую схему перед продолжением.
Второй шаг: такие системы никогда не существуют в вакууме. Существует ли уже общеорганизационная схема для идентификаторов пользователей и/или заказов, например, в системе учета, управления запасами или CRM? Если это так, подумайте об использовании существующих схем для облегчения взаимодействия. Многие крупные организации имеют несколько способов указать одного клиента или заказ, и это просто делает получение полезного интеллекта из данных, которые намного сложнее.
Третий шаг:, если старая системная схема слишком ужасна, чтобы продолжить, и нет другой схемы для принятия, сверните свой собственный. В этом случае посмотрите на недостатки исходной схемы, что бы они ни были, и исправьте их. Правильный ответ будет зависеть от конкретных требований приложения. Заявление о проблеме, которое вы нам дали, слишком расплывчато, чтобы правильно рассуждать о том, как может выглядеть окончательная форма.
Я всегда придерживаюсь номеров автоматического инкремента, и я всегда забираю последовательность достаточно высоко, чтобы все они имели последовательное количество цифр - кажется, менее запутанным.
Я также иногда начинаю номер заказа, скажем, 6 цифр, начиная с 200 000 и номера клиентов с 5 цифрами, начиная с 10 000, которые, например, дают мне 90 000 уникальных номеров клиентов и 800 000 уникальных номеров заказов, и вы всегда можете скажите, просто посмотрев на это, был ли это номер клиента или номер заказа. (т.е. если представитель клиента запрашивал номер по телефону, он сразу же был бы очевиден, что и есть)
Я бы, однако, не создал логику в приложении, которая будет зависеть от этого, поэтому, даже если бы она перевернулась, системе все равно.
Самая большая проблема здесь - попытаться не переубедить проблему.
Хотя я более опытен в системах электронной коммерции, я думаю, что некоторые из пунктов, сделанных в этом сообщении, могут применяться к системам почтовых заказов и телефонных заказов.
Для заказов целое число с автоматическим приращением отлично работает как первичный ключ в базе данных, а также номер, который клиент увидит на его/ее счете. Нет абсолютно никаких оснований для создания сложного алгоритма для ваших номеров. Если вы хотите указать, в какой стране/регионе они используют отдельное поле в вашей базе данных. Также, если вас беспокоят ваши конкуренты, шпионящие за вами; позволь им! Если ваш бизнес вращается вокруг шпионажа на ваших конкурентов, потому что вы не получаете достаточный доход, скорее всего, ваш бизнес не очень хорош в первую очередь. Кроме того, если вы хотите обмануть своего конкурента, вы можете просто создать свой собственный script, который будет автоматически создавать поддельные заказы. Если ваша система электронной коммерции хорошо разработана, это не будет проблемой.
Ключевые вещи, использующие целое число с автоматическим приращением:
Всякий раз, когда вы разрабатываете, вы всегда должны начинать с того, что лучше всего для клиента. В конце концов, это те, кто кладет пищу на ваш стол. Счастливый клиент - возвращающийся клиент.
Для меня предпочтительным является получение комбинации даты + счетчика для сегодняшней транзакции. Мне было предложено выбрать номер из 5 цифр. Таким образом, я придумал следующее ниже:
Я решил использовать подсчет большего, чем десятичный (10), поэтому я использую базу 16 для подсчета. Таким образом, если я получу максимум 5 цифр из шестнадцатеричного (FFFFF), то это будет 1 048 575 пунктов. Объединяя дату, могу сказать, что могу получить 1 048 575 штук в день. Поэтому, чтобы каждый день подсчитывать количество, я смешал дату, получив следующую сумму:
Таким образом, у меня будет максимум 3 символа для моего подсчета. Так что это будет текущая транзакция XXX + Todays. Пример:
Текущая дата: 2014-12-31 13:22 PM Дата реализации: 2010 Общая сумма текущих транзакций: 100
Количество: (5 + 13 + 365) + 101 = 383101 Номер для заказа: AD-5D87D
AD имеется только специальный префикс номера заказа. Таким образом, к тому времени, когда я буду не в порядке, который будет 1000000 лет с момента моей даты реализации.
В любом случае, это нехорошее решение, если вы считаете, что ваша транзакция в день может быть высокой, как 1000000.