Comments 5
Это ж надо так много и так наукообразно написать о таком банальном и всем до боли знакомом явлении
Контент о товареЕще два с половиной вида:
— Комплектация
— Связи с объектами, не являющимися товарами (по крайней мере, в этом магазине)
— Артикулы по различным каталогам (может быть смешан с другими видами контента, а может и нет)
первые два я бы тоже отнес (по крайней мере, с точки зрения общей теории) к связанным товарам (даже если эти товары — нетовары, например, мы так использовали каталог компьютерных интерфейсов)
а вот артикулы — это по сути ключи, по которым производится стыковка с внешними данными, т.е. это часть операторв импорта/экспорта, хотя, конечно, можно ряд атрибутов назвать ключевыми, и их использовать в том числе и таким образом.
мы у себя такие поля как партномер, артикул, прайсовое название, EAN-коды и т.п. не рассматриваем как часть информационной модели, а как атрибуты сущностей в смысле теории баз данных, т.е. это более низкий уровень информациио о товаре. В частности, есть альтернативные значения данных полей для более успешной работы системы матчинга по ключевым полям (правила матчинга используют сравнение ключевых полей с помощью нескольких видов сравнений).
а вот артикулы — это по сути ключи, по которым производится стыковка с внешними данными, т.е. это часть операторв импорта/экспорта, хотя, конечно, можно ряд атрибутов назвать ключевыми, и их использовать в том числе и таким образом.
мы у себя такие поля как партномер, артикул, прайсовое название, EAN-коды и т.п. не рассматриваем как часть информационной модели, а как атрибуты сущностей в смысле теории баз данных, т.е. это более низкий уровень информациио о товаре. В частности, есть альтернативные значения данных полей для более успешной работы системы матчинга по ключевым полям (правила матчинга используют сравнение ключевых полей с помощью нескольких видов сравнений).
Атрибуты могут быть числовыми, категориальными и текстовыми.
Еще могут быть даты (сроки изготовления, годности и т.п.). И бинарные атрибуты тоже в ряде случаев стоит отличать от категориальных.
А еще могут быть комбинированные атрибуты (по аналогии со структурами в языках программирования).
Да, если вспомнить типизацию из языков, то можно далеко зайти) Я бы все-таки даты и логические относил к числовым, т.к. на них есть очевидная арифметика и линейное упорядочение (по сути это Z и Z/2Z). А все остальные шкалы пойдут уже в категориальные.
Комбинированные ни разу не приходилось использовать, хотя вполне можно себе представить их. Но я бы их все равно расплиил на более простые внутри рабочей системы, а на стороне проекта уже бы склеивал в нужные комбинации экспортными шаблонами.
Комбинированные ни разу не приходилось использовать, хотя вполне можно себе представить их. Но я бы их все равно расплиил на более простые внутри рабочей системы, а на стороне проекта уже бы склеивал в нужные комбинации экспортными шаблонами.
Sign up to leave a comment.
Об информационной модели товара