Настроятельно рекомендуется всем разработчикам и участникам БД регистрации корпоративных процессов обеспечивать уникальные заголовки всем типам объектов.
Понятно что Продукт имеет символическое имя, всегда уникальное проблемы нет. Внутренние Задачи тоже так или иначе избегают совпадения заголовков топиков. Изделия/Экземплярыимеют серийные номера, включающие ссылку на продукт. Имена Полей уникальны (в т.ч. по требованиям Udb). Заголовками Заказов, Спецификаций и подобного могут быть даты создания или уникальные порядковые ИД если фантазии не хватает на иное. Пользователи, Роли и прочая системная туфта именуется ни на что другое не похожими идентификаторами. Файлы аттачментов если не уникальны по именам, могут включать полный путь либо ревизию.
Между разными классами объектов конфликтов тоже легко избежать. Если есть уже пользователь "AV" а в поставку заказа надо включить антивирус не надо называть его позицию "AV". Сойдет "A/V", "Antivitus". Практической проблемы нет.
Главная проблема - это номера версий и ревизий.
Для версий разных продуктов и компонентов (в т.ч. закупочных) надо вводить правила их размежевания.
Если скажем версия прошивки одного контроллера названа "3.15" и прошивка другого тоже "3.15" возникают тонны проблем.
Потребуется вводить и отслеживать "пространство имен". Во всех мыслимых контекстах приписывать к этому номеру название продукта. Но это не спасет от других проблем.
Одна из важных фундаментальных проблем восприятия это что кто то может подумать что прощивка "3.15" одного контроллера совместима с "3.15" другого. Это не факт! Совместимость должна определятся статусами специальных перекрестных связей а не закладываться в заголовках.
Причем для версий к их номеру нужно относится как к первичному ключу в БД (даже если они имеют номер топика и Udb key) так как их нельзя переименовать. Нельзя после тестирования совместимости перенумеровать версии чтобы они отражали что то осмысленное.
Multiscanex 2.501e AVKB-Ex2A A1.101
Естественно имеем проблему дублирования информации и всякие рассогласования при переименовании. Плюс просто кучу неуклюжего мусора.
Для каждого продукта использовать свой уникальный формат.
1.1001ex
1.9752q2
3.2010rtx A1D3.3.omega
A1D3.3.vista
A2E5.5.tempo B2a.001
B2b.007
B5i.002 FW2000.Mcu1.a
FW2001.Mcu1.b
FW2034.Mcu1.d FW2010.Mcu2.a
FW3000.Mcu2.s
FW3001.Mcu2.qМожно даже шаблон формата привязать к продукту для автоматической верификации. Логически соседние Продукты могут иметь схожие форматы.
Принцип выбора - кто первый захватил формат тот и прав. Остальные обязаны придумать что угодно, но отличное.
Для сотен наших Продуктов реально придумать разные форматы.
В формате не надо искать глубокой логики. Просто произвольно разные и все. Это правда одна из проблем для инженеров - произвольность, начнутся споры и переживания ниочем... Это будет работать только если один человек, понимающий цель идеи будет устанавливать правила.
Приписываем к номеру версии 2-3 буквы префикса, уникального для продукта.
Очевидный подход - сокращение от названия продукта может быть опасен. Будут переживания и путаница при переименовании продукта и от коллизий по похожести.
Поэтому правило требующее скажем двух случайных букв обязательно НЕ совпадающих с продуктом
Multiscanex
Qi.2.501e
Qi.3.502fx.2 AVKB-Ex2A
RmA1.101
RmA1.202Комбинаций 2 букв много но не бесконечно http://en.wikipedia.org/wiki/Wikipedia:List_of_two-letter_combinations
Нужно учитывать что первая буква должна быть обязательно заглавной (вики!) и однозначно латинской.
Для всяких компонентных и закупных продуктов можно ввести три буквы.
Проблемы применения поиска - очевидны. Их можно как то невилировать автоматическим префиксированием объектов.
Но такие вещи как autocomplete ссылок на объекты по их именам или скриптинг в формате, например:
"B5i.001" -> Status = Success;
может не поддерживать (и с моей стороны НЕ будет) пространства имен и разрешения неоднозначностей.