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

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

Причем здесь суррогатные, псевдо-суррогатные ключи и правила именования? Первичным ключом таблицы может быть что угодно, хоть автоинкремент, хоть GUID для особо эстетствующих маньяков. Наименованием может быть что угодно и даже на каком угодно языке. Здесь же речь идет о некоей человекочитаемой кодировке номенклатуры. Можно назвать артикулом, можно кодом, от этого суть не меняется.

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

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

2. Как показывает практика, скорость работы оператора, набивающего строчки документов при помощи артикулов в разы выше использования любых других способов. Опять таки, при грамотном построении системы кодирования 80-90% часто используемых оператором артикулов запоминается наизусть. Аналогично при быстром поиске и отборе. Допустим надо мне быстро в остатках найти типлен с полипропиленом. Я помню, что артикулы на хим.сырье нижнего уровня начинаются с 001. Мне достаточно набрать эти 3 цифры, чтоб получить значительно сократившийся список, в котором нужное легко сразу найти глазами. Без этого придется либо искать по названию, и возможно не один раз, либо привлекать иерархию групп номенклатуры. Оба этих варианта скорее всего окажутся более затратными по времени, кликам, нажатиям. Оптимизацией скорости работы операторов приходилось заниматься достаточно много. Вылизывали местами до каждого нажатия.

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

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

Достаточно примеров?

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

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

guest_20040621

> Причем здесь суррогатные, псевдо-суррогатные ключи и правила именования?

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

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

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

Ага. Офигенно человекочитаемая кодировка 35.08.102.004. Ну и что скрывается под этим именем?

Для человека "в контексте" такая кодировка скажет очень и очень многое. Даже если он ранее ни разу не встречал именно такую позицию.
guest_20040621
> 1.

Так и представляю себе оператора, держащего в голове этот "ассортимент, исчисляемый сотнями тысяч". Гениальный человек.

Нет таких. Можно держать в голове относительно узкий набор кодов, а так же небольшие принципы классификации и формирования этих самых кодов. Из _моей_ практики: когда продажникам внедяли этот самый ввод по артикулам, то при ассортименте готовой продукции порядка 10 тыс, описание некоторых артикулов на листочке бумаги площадью с пачку сигарет описывало 80% частоупотребимого - эдакая шпаргалка на монитор. (справедливости ради стоит заметить, что именно в отделе продаж ввод по артикулам так и не приняли. За то приняли на производстве, где документооборот на порядки больше)
guest_20040621
> 2.
Следует делать оговорку: "как показывает _моя_ практика". Моя же практика говорить о том, что ручной ввод - это 3% ошибок.

Да, разумеется. А чему это противоречит в описанном? Выбирать из классификатора или искать по названиям - это уменьшит число ошибок? Дальнейший контроль по разным критериям снижает кол-во оставшихся ошибок к допустимому минимуму.
guest_20040621
> 80-90% часто используемых оператором артикулов запоминается наизусть
Ага. На прошлой неделе вот такой оператор в "Перекрестке" насчитал мне 380 рублей за пачку сигарет. Контрольный вопрос: сколько цифр кода девушка набрала неправильно?

С розницей не работал. Но и тут, полагаю, достаточно способов коррекции ошибок: визуальный контроль названия, сумм и т.п.
guest_20040621
> найти типлен с полипропиленом

Конечно, запомнить кодирование номенклатуры - это сильно проще, чем просто набрать на клавиатуре "типлен".

Верхний уровень, а так же вглубь по часто используемым запоминается САМО СОБОЙ в течение достаточно короткого времени без специальных дополнительных усилий для этого. Разумеется, при условии прозрачной и понятной схемы кодирования.
guest_20040621
> Наиболее простой и удобный способ обеспечить однозначную идентификацию изделия между
> такими базами - это именно артикул
Чушь. Единственное, что требуется для интероперабельности - это уникальность идентификаторов.

НУ ТАК И Я ПРО ТО ЖЕ!!! Вопрос только в том, что в данном варианте понимается под идентификатором? Первичный ключ? Часто невозможно даже в рамках холдинга. Вводить отдельный идентификатор для обмена? Так вот же артикул! Чем плох?

strizhУ нас бензин кодировался так типа:
А95-3.85 (95-й по 3.8500)

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

Давай-ка терминологию уточним. Если под идентификатором понимается первичный ключ, используемый в БД, то тут я всецело соглашусь. Хотя.... Лично для себя я нашел одно исключение из этого правила. Это справочник стран. Там для первичного ключа используется сокращенное международное двухбуквенное обозначение страны.
guest_20040621
Любые другие идентификаторы - это _дополнительное_ кодирование. Какие задачи и как оно решает - дело десятое. Автор же пишет: "...по коду всегда можно найти всю историю его движения...", что говорит о том, что это дополнительное кодирование используется как основное. Саша, ну ошибка это, как ни крути. Причем, ошибка принципиальнейшая.

Тут проще дождаться автора и спросить. Если речь шла про первичный ключ, тогда да, это грубая ошибка. Я же делал акцент именно на атрибуте, который может являться альтернативным ключом, но преследует вполне определенные цели, которые я и описал. Тот же dmitry_do тоже скорее всего в таком аспекте рассматривал вопрос.
guest_20040621
(поэтому и нужен, кстати, отдельный человек; хотя на самом деле он получает заработную плату только потому, что базу данных проектировали абсолютно безбашенные люди).

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

guest_20040621> для себя я нашел одно исключение из этого правила

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

Кому обязан? Независимым от чего? Нет под рукой Дейта. Вот нашел:

Ключ отношения - атрибут отношения, однозначно идентифицирующий каждый из его кортежей

Но подозреваю, что в форумах по проектированию было уже море священных войн про естественные vs суррогатные ключи, так что лучше тему не развивать. Для практического применения использование RU, US, GB и т.д. для однозначной идентификации страны я лично нашел очень удобным и не имеющим прогнозируемых за обозримое время жизни системы отрицательных последствий.
guest_20040621
> наиболее распространенная структура справочника номенклатуры

"Распространенная" - не значит "правильная". Ошибки вообще тиражируются охотнее хороших решений.

> гарантированно избежать разночтений практически невозможно

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

Yul_yul

Недостатки:
не хватает значности 3х-значного кода материала;

Варианты:
1. не ограничиаться 3 знаками
2. не ограничиваться цифрами
3. пересмотреть методику кодирования
4. (отдам должное коллегам) пересмотреть потребность в такой кодировке вообще. может она и правда не нужна.

2 guest_20040621: Вернемся к теме артикулов?
guest_20040621
> Вводить отдельный идентификатор для обмена? Так вот же артикул! Чем плох?

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

У артикула, как и у любого другого кода, в принципе главное применение одно - идентификация. В чем его ограниченность? И какие возможны альтернативы для решения задач той же интероперабельности:
а) между разными системами в рамках "корпоративного зоопарка" (не в негативном смысле этого слова)
б) между разными субъектами
в) для публичного применения
?
Просто любопытно. Да, теоретически можно обойтись без подобной системы кодирования.
Хоть я и не считаю, что миллион леммингов не может ошибаться, но тем не менее обратимся к массовым примерам. У большинства поставщиков есть артикулы. Вон запчасти к иномаркам обычно легче всего искать по каталожным номерам. Гляжу прайс на компьютерные комплектующие - тоже артикулы. И так почти везде, кроме разве что продуктового магазина :)
Зачем?

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

http://www.akzhan.midi.ru/devcorner/articles/naturalKeysVersusAtrificialKeysByTentser.html
http://sql.ru/forum/actualthread.aspx?tid=177277&hl=%f1%f3%f0%f0%ee%e3%e0%f2%ed%fb%e5
/topic/13826&pg=1
/topic/13826&pg=1
/topic/104535&pg=1

В проектировании БД ей самое место, кому интересно - можно попытаться поднять новый спор, но скорее всего пошлют в поиск. (Кстати, guest_20040621 там похоже собаку съел на этих спорах )

Здесь эту тему дальше развивать не надо. Все-таки про кодирование ТМЦ топик.

guest_20040621
> похоже собаку съел

Есть что-то плохое в том, что я умею проектировать базы данных? Я бы с удовольствием поговорил об информационных системах вместо того, чтобы обсуждать ошибки.
Ошибки - тоже понятие относительное
Не надо доходить до крайностей в следовании теории. Относительная скорость двух тел, движущихся навстречу друг другу тоже ведь считается в теории не как сумма двух скоростей, а по гораздо более сложной формуле. Но ведь никто не объявляет тут об ошибке, ибо до скорости света нам еще очень и очень далеко и для практических применений простая формула более чем приемлема. Так же и в других областях, в том числе и в проектировании БД, могут быть допущения, приемлемые в локальных условиях, хотя и ошибочные в общем случае.
Поэтому, вернемся таки к артикулу, который рассматривается не как первичный ключ номенклатуры, а лишь как дополнительный идентифицирующий атрибут.

Сахават Юсифов Александр ГoлдунВон запчасти к иномаркам обычно легче всего искать по каталожным номерам. Гляжу прайс на компьютерные комплектующие - тоже артикулы.
Зачем - ясно. Хоть как-то облегчить жизнь.
А вот если на детали стерся код? Что будете делать? КАк еще можно эту деталь идентифицировать?
Иногда оказывается просто никак! Идентифицировать по телефону, имея на другом конце менеджера, не являющегося автоспецом, может оказаться почти невозможным.

guest_20040621> У артикула, как и у любого другого кода, в принципе главное применение одно - идентификация.
> В чем его ограниченность?

Не приходило в голову, что артикулы могут совпадать у совершенно никак не связанных друг с другом товаров/услуг/предприятий?

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

guest_20040621
Не "какие возможны", а "что есть лучше стандартного решения". А стандартное решение выглядит примерно так (на самом деле совсем не так, но сейчас это не принципиально): [идентификатор источника].[пространство имен источника].[идентификатор сущности источника]. Вы хотите располагать только и исключительно последним идентификатором.

Ну да, если я работаю в рамках неизменного [идентификатор источника].[пространство имен источника].
Но эта самая "ограниченность" не мешает прекрасно справляться с задачей приведения к общему языку разнообразных систем: производственная КИС, какие-то сторонние системы, web-сайт, системы дилеров и торговых предприятий холдинга и т.д.
guest_20040621
В общем случае - это источник геморроя. Ну вот возьмите, например, то же штрихкодирование - там похожий на описанный алгоритм идентификации. Наверное, его не полные идиоты придумали?

Хороший пример. Он наглядно показывает тезис, что чем более универсальная система, тем менее она удобна для частных случаев применения. Глядя на EAN13 легко с ходу определить страну. Ну может еще что-то чуть-чуть. А вот дальше - увы, темный лес. В чистом виде суррогат.

guest_20040621
> теоретически можно обойтись без подобной системы кодирования
Опять же не в этом дело. Не стоит задачи непременно обойтись без дополнительного кодирования.

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