Как можно бороться с деблями в БД.

← →
Kolan © (2007-12-07 17:46) [0]

Здравствуйте,
Сегодня мне показали что существует сабжевая проблемма, и как с ней легко бороться я пока не придумал.

Проблемма такая:
Допустим у нас есть справочник чего угодно, но большой.

Оператору надо выбрать строку из справочника а если её там нет, то добавить её туда.

Сценарий выглядит так:

1. Оператору надо выбрать строку.
2. Он запускает поиск и ищет «Красные томаты»(ищет ессно не точную фразу, а например Кр* где * любая посл символов, или LIKE «Кр»% в MS SQL).
3. Такой строки нет, и он добавляет её.

Но оказывается она там была, только называлась «Помидоры красные».

Вопрос как сделать так, чтобы таких дублей небыло?

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

ЗЫ
Пример про продукты  просто пример. Никаких штрих кодов нет, то есть можно считать что к оператору приодит чел, и говорит у меня «красные томаты»&#133

← →
megabyte © (2007-12-07 17:49) [1]

Делать справочник1 на поле в твоем справочнике и связь по ключу, чтоб вводили только записи, соотв. в таблице справочника1

← →
wicked © (2007-12-07 17:52) [2]

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

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

← →
Kolan © (2007-12-07 17:54) [3]

> [1] megabyte © (07.12.07 17:49)
> Делать справочник1 на поле в твоем справочнике и связь по
> ключу, чтоб вводили только записи, соотв. в таблице справочника1

Нет таблица такая:

ID Name
1 Помидоры красные
2 Финики в собственном соку
3 Бананы жареные с муровьями
&#133
10000 Вобла

К оператору приходят и говорят У меня Красные томаты, его задача нати товар в справочнике, а если его там нет, то ввеси его.

Я не понял что вы предлогаете&#133

← →
Kolan © (2007-12-07 17:55) [4]

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

Эти способы мне известны, бо они и используются сейчас. Хотелось бы избезать ошибки технически.

← →
Черный Шаман (2007-12-07 18:01) [5]

> Kolan © (07.12.07 17:46)

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

Морфологический словарь сделать, заполнить и прикрутить недолго.

← →
turbouser © (2007-12-07 18:07) [6]

> Kolan © (07.12.07 17:46)

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

← →
Kolan © (2007-12-07 18:07) [7]

> Морфологический словарь сделать, заполнить и прикрутить
> недолго.

Вот и я о нем думаю, точнее думаю я о яндекс сервере, только пока не понял как им пользоваться&#133

Еще есть идеи?

← →
stone © (2007-12-07 18:08) [8]

> 2. Он запускает поиск и ищет «Красные томаты»(ищет ессно
> не точную фразу, а например Кр* где * любая посл символов,
> или LIKE «Кр»% в MS SQL).

ну раз такой бардак допустим, то почему бы не сделать LIKE "%Кр% "

← →
Kolan © (2007-12-07 18:12) [9]

> ну раз такой бардак допустим, то почему бы не сделать LIKE
> "%Кр% "

А в чем бардак?

%Кр%
Это не поможет, к тому же такой поиск вернет оч. много лишнего(Креветки живые) и опятьже оператору будет лень искать и он сделает дубль.

← →
stone © (2007-12-07 18:19) [10]

> Kolan © (07.12.07 18:12) [9]

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

← →
@!!ex © (2007-12-07 18:26) [11]

Делать зависимость не только от имено:

Надо ввести "Красные томаты".
Оператор выбирает категорию:
Продукты
Натуральные
Ягоды(помидоры - это вроде ягоды)
Красные

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

← →
Правильный_Вася (2007-12-07 18:30) [12]

а иерархический справочник (овощи, рыба, вино) с дополнительными галками (состояние - свежее, консервированное, мороженое, вяленое; цвет - ..., производитель - ..., ...) ?

← →
Anatoly Podgoretsky © (2007-12-07 18:59) [13]

> stone (07.12.2007 18:19:10) [10]

Бардак не автоматизируется.

← →
Правильный_Вася (2007-12-07 19:07) [14]

> бороться с деблями

нехорошие ассоцииации вызывает

← →
PEAKTOP © (2007-12-07 19:35) [15]

> Вопрос как сделать так, чтобы таких дублей небыло?

Когда-то тоже существовала такая проблема. Пришел к ней к заказчику и объяснил, как есть и почему я не могу решить эту проблему. Заказчик предложил выход: штраф оператору ввода данных 10$ за каждый дубль в первом месяце, зато мои ребята должны были после этого месяца "почистить" базу от дублей.

В результате: после первой "отрицательной" зарплаты каждая из операторов запомнила до 8000 позиций наизусть по кодам (ID) !!!

А Вы говорите ...

← →
boriskb © (2007-12-07 20:11) [16]

> PEAKTOP © (07.12.07 19:35) [15]

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

Ох уж эта уверенность во всесилии программ!
Постоянно здесь подобные посты :(

← →
Sergey Masloff (2007-12-07 20:34) [17]

boriskb © (07.12.07 20:11) [16]
А у нас не кладовщики. И людям работать надо а не номенклатуру учить. Поэтому все проблемы решает программа. А люди занимаются своим делом - зарабатывают деньги для компании.

А посты - чего ж им не быть это ж легче чем продумать механизм облегчения жизни людям

← →
kaif © (2007-12-07 21:27) [18]

Здесь существуют 2 разные проблемы.

Проблема 1.
Проблема дубликатов (нехорошо, когда возникают 2 эквивалентных экземпляра одной сущности). Это проблема решаема. Например, я предоставляю "поиск по вхождению кусочков наименований с сужением по принципу &". Если человек искренне не хочет дубликатов, то, набирая "hp дж", он найдет все "картриджи HP". Набирая "hp", он уже нашел всю продукцию Хьюлетт Паккард, а, набирая (через пробел после "hp") "дж", он уже нашел все картриджи. Троебование "искать прежде, чем добавлять" выполняется автоматически благодаря тому, что я позволяю "добавлять с редактированием", то есть: человек нашел картридж с похожим названием, скопировал имеющийся прецедент и изменил в названии лишь пару символов, сохранив результат в качестве нового элемента. Это автоматически создает некие паттерны или традиции именований, которые легко выдержать, не напрягаясь, благодаря поиску "по кусочкам, сужающим по &".

Проблема 2.
Проблема законодательства, требующая искусственного введения дубликатов (по сущности) и ведения раздельного учета "томатов свежих" и "свежих томатов", так как в одной накладной фигурировали "томаты свежие", а в другой - "свежие томаты". И с точки зрения налоговой инспекции это - совершенно разные товары и их ни в коем случае нельзя смешивать.
Сия проблема государственного идиотизма решается либо путем применения зарегистрированных в Европе штрих-кодов, либо путем приказа дирктора "Считать томаты свежие и свжие томаты одним и тем же видом товара". То есть проблема решается организационно, программист в одиночестве эту проблему решить не в силах.

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

← →
PEAKTOP © (2007-12-07 21:42) [19]

> "Считать томаты свежие и свжие томаты одним и тем же видом товара".

Мда-а, проблема актуальна...

Кстати - мысль, спасибо. А насчет налогового учета, благо в Украине это не актуально.

← →
Sergey Masloff (2007-12-07 21:54) [20]

>программист в одиночестве эту проблему решить не в силах.
Вот именно эту проблему решить не так сложно. Достаточно построить цепочку зависимостей (в зависимости от задачи - возможно с периодами - тогда еще более широкий областью охвата).

То есть в накладной №1 ссылка на "томаты свежие" которые и занесены в справочник
В накладной №2 в справочник ошибочно занесли "свежие томаты"
В накладной №3 все пришло в соответствие и опять "томаты свежие"

Достаточно в справочнике предусмотреть дедуплицирующую ссылку. То есть при обнаружении в накладной №2 "свежих томатов" в этот элемент вносится дедуплицирующая ссылка на "томаты свежие". По умолчанию дедуплицирующая ссылка равна уникальному идентификатору. Запись у которой они не совпадают считается "устаревшей" и например при выборе из справочника варианитов для новых накладных не отображается. В то же время при повторной печати старой накладной или отчета по ней можно в зависимости от желания демонстрироать оригинальное или истинное название. Управленческую отчетность можно строить по "выверенным" значениям то есть в управленческом отчете будут только "томаты свежие" а в остальных - как нужно в данный момент. И не зависишь ни от каких организационных решений. Кстати дедуплицирующие ссылки могут выстраиваться в цепочки, а если в них еще предусмотреть хранение диапазонов действия....

← →
Ломброзо © (2007-12-08 00:32) [21]

Про алгоритмы типа soundex забыли упомянуть

← →
turbouser © (2007-12-08 00:35) [22]

> Ломброзо © (08.12.07 00:32) [21]
>
> Про алгоритмы типа soundex забыли упомянуть

Это не поможет.

← →
Petr V. Abramov © (2007-12-08 13:24) [23]

> Как можно бороться с деблями в БД.
> Оператору надо выбрать строку из справочника а если её там нет, то добавить её туда.

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

Проблема решается организационно, как - универсального рецепта нет, надо разбираться, что за предприятие.

> PEAKTOP © (07.12.07 19:35) [15]

> В результате: после первой "отрицательной" зарплаты каждая
> из операторов запомнила до 8000 позиций наизусть по кодам
> (ID) !!!

Коды должны быть не ID, а значащие
10 - томаты
20 - бананы

1 - красные
2 - зеленые

таким образом
101 - томаты красные
202 - бананы зеленые

уже не запутаешься

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

> Sergey Masloff (07.12.07 21:54) [20]
решение красивое, но не из серии ли "автоматизированный бардак"?

← →
PEAKTOP © (2007-12-08 13:37) [24]

> Коды должны быть не ID, а значащие
> 10 - томаты
> 20 - бананы
>
> 1 - красные
> 2 - зеленые
>
> таким образом
> 101 - томаты красные
> 202 - бананы зеленые

И шо, одно другое исключает ?
Понятно, что ID получается из генератора(Intebase/Firebird) или переменной (MySQL). Но если это "смысловая" группа товаров, а не производственная калькуляция, то почему бы и не разрешить править коды пользователю ?

Ну таки, можно еще добавить к товарам дополнительные аттрибуты, и в триггере перед вставкой выставлять в ID эти цифры, как ты говоришь, прибавлять к ним уникальный номер из генератора и получать "осмысленный" ID. Например
1002145158
100 - группа
2 - марка
14 - фирма производитель
5158 - ID товара из генератора.

← →
Petr V. Abramov © (2007-12-08 13:54) [25]

> PEAKTOP © (08.12.07 13:37) [24]
а ключ и смысловой код - разными полями проще сделать

> 5158 - ID товара из генератора.
и зачем оно юзеру?

← →
boriskb © (2007-12-08 14:02) [26]

> Sergey Masloff (07.12.07 20:34) [17]

Здесь можно долго (и всего вероятней бесплодно) спорить.
Поверь на слово (если сам не встречался) - куча ситуаций, в которых твой алгоритм не сработает.
А то, что нужно облегчать жизнь - кто ж спорит? Для этого мы и есть.

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

← →
Petr V. Abramov © (2007-12-08 14:02) [27]

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

← →
Anatoly Podgoretsky © (2007-12-08 14:06) [28]

> Petr V. Abramov (08.12.2007 14:02:27) [27]

Придет.
Сказано же, что бардак нельзя автоматизировать.

> Anatoly Podgoretsky © (08.12.07 14:06) [28]
придет-то придет, только после N неудачных попыток затея будет брошена. Другой вопрос, что N может быть сколь угодно велико.

> Anatoly Podgoretsky © (08.12.07 14:06) [28]

к тому же если кто-то введет "помидоры рыжие", его сразу воспитает коллектив, который не нашел номенклатуру.

> Сказано же, что бардак нельзя автоматизировать.

Сейчас грамотные аналитики встречаються реже амурских тигров. А из программиста какой аналитик ? Он пользователей не понимает.

2 Sergey Masloff
Если бы задача ограничивалась набором документов, то это решение, пожалуй, наилучшее. Хотя есть и другие решения, например, введение отдельных таблиц, хранящих парами синонимы. Но это, скорее, техническая вариация того же приема - в управленческом (правильнее называть - черном) учете иметь данные фактические, а в официальном - данные "соответствующие закону, но не здравому смыслу".
К сожалению, многие программисты не знают закон.
И бухгалтера не знают.
Или прикидываются.
А закон допускает кроме накладных в качестве первичных документов использовать и так называемые бухгалтерские справки, и приказы директора, и пункты учетной политики. Важно лишь одно - на фирме должен существовать документ, декларирующий тот факт, что фирма в учете считает "томаты свежие" и "тумат свежий (согласно тексту накладной от безграмотного поставщика)" одним и тем же видом товара.
Сначала нужно разобраться с этим в организациолнном смысле, а дальше - дело техники. Не исключен даже вариант, что накладная хранит и ссылку на ID действительно уникального объекта учета, и просто текст его наименования в данном случае. Это не так много отнимает места, как может показаться. Сто тысяч строк накладных со средней длиной наименования 30 символов добавит всего 3 мб к размеру базы данных.

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

> а иерархический справочник (овощи, рыба, вино) с дополнительными
> галками (состояние - свежее, консервированное, мороженое,
> вяленое; цвет - ..., производитель - ..., ...) ?

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

> Например, я предоставляю "поиск по вхождению кусочков наименований
> с сужением по принципу &". Если человек искренне не хочет
> дубликатов, то, набирая "hp дж", он найдет все "картриджи
> HP". Набирая "hp", он уже нашел всю продукцию Хьюлетт Паккард,
> а, набирая (через пробел после "hp") "дж", он уже нашел
> все картриджи. Троебование "искать прежде, чем добавлять"
> выполняется автоматически благодаря тому, что я позволяю
> "добавлять с редактированием", то есть: человек нашел картридж
> с похожим названием, скопировал имеющийся прецедент и изменил
> в названии лишь пару символов, сохранив результат в качестве
> нового элемента. Это автоматически создает некие паттерны
> или традиции именований, которые легко выдержать, не напрягаясь,
> благодаря поиску "по кусочкам, сужающим по &".

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

> Коды должны быть не ID, а значащие
> 10 - томаты
> 20 - бананы
>
> 1 - красные
> 2 - зеленые
>
> таким образом
> 101 - томаты красные
> 202 - бананы зеленые
>
> уже не запутаешься

Пробовано. Так кодировали товары в советском автоматизированном учете. Помню простыни в управлении военторга :)
Жутко неудобно. Заставлять обычного оператора (не товароведа) все это зубрить - издевательство. Плюс очень тяжело рассчитывать количество позиций под код каждой характеристики.

> ANB © (08.12.07 17:23) [33]
> Так кодировали товары в советском автоматизированном учете.
так кодируют и в крупных западных компаниях, типа как-колы :)

> Заставлять обычного оператора (не товароведа) все это зубрить - издевательство.
а не надо заставлять зубрить. Поиск по названию никто не отнимает, поэтому часто встречающиеся позиции запоминаются сами, а редкие - ну по like достать можно. Если людей как следует замучить :) они очень быстро оценивают преимущество по скорости работы с кодами. А если три бумажки в день - тогда у них времени много, могут посвяить его интеллектуальному поиску дублей.

> А закон допускает кроме накладных в качестве первичных документов
> использовать и так называемые бухгалтерские справки, и приказы
> директора, и пункты учетной политики.

Это арбитраж только учитывать будет. В реале налоговая, не очень такое любит. В понятие налоговой "товар" наименование не входит, хоть мандарины к томатам припиши. Но если товар импортный, то обязательно нужно уметь доказать, что он указан, как в декларации и с номером ГТД. Показать, что ты продал столько-то товара и это именно этот товар, он приходил именно по такой цене - ты обязан.

> они очень быстро оценивают преимущество по скорости работы
> с кодами.

Ой не ври, так оценят - потом будешь выяснять, какой ХХХ не к той коробке приклеил штрихкод. Административные штрафы рулят.

> tesseract © (08.12.07 18:48) [35]
штрих-коды ни при чем.
> потом будешь выяснять, какой ХХХ не к той коробке приклеил штрихкод.
буду, никуда не денусь. можно только минимизировать.
> Административные штрафы рулят.
они должны иметь ЧЕТКОЕ основание.
P.S. на том предприятии, с которым работаю, это на грани предела. Где работал - и без штрафов за ошибки помнили, все просто - работу не сделал - домой не пошел,а если пошел - то навсегда.

Тема-то очень важная, на самом деле. Решение Sergey Masloff мне лично очень нравится. Даже не решение, а само понятие "дедуплицирующей ссылки". Однако это все сработает лишь при условии некоторого регламента: имеется ответственный за периодическое впроведение "дедуплицирующей инвентаризации". Очень хочется послушать о зарубежных решениях этой проблемы. Я так слышал, что в США существуют налоги. И налоговые инспекторы. Но я не слышал о том, чтобы в США существовала подобная проблема. Не хочу гадать. Может быть те, кто работает в Штатах, смог бы нам пролить свет на ситуацию? Так где выход? В штрих-кодах? Или в том, что не бизнес для налогов, а все же налоги для бизнеса? Или как?

> kaif (08.12.2007 22:16:37) [37]

Налоговики правы, иначе нефть превращается в скважную жидкость

> kaif © (08.12.07 22:16) [37]
для российских товаров пофиг, как он написан в неграмотной накладной. Если "сосиски" написано через мягкий знак, в налоговом учете можно проводить как "мясопродукты".
Для импортных - главное, чтоб номер ГТД был. И как оно в накладной написано - проблема поставщика, в принципе может писать в соотв. с ТНВЭД, и расписывать мясопродукты на колбасу и сосиски - его добрая воля.
Не даром в ГК проскакивает понятие "здравый смысл".

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

Как можно бороться с деблями в БД. Найти похожие ветки