Контроль уникальности реквизита справочника |
Я |
09.08.12 — 17:51
Каким образом нужно правильно это делать?
1 — 09.08.12 — 17:52
В обработке проверки заполнения
2 — 09.08.12 — 17:53
Как вариант
3 — 09.08.12 — 17:54
Если нужно обеспечить контроль и при тупой программной записи, тогда в перед записью.
4 — 09.08.12 — 17:54
Перед записью контролировать неправильно
5 — 09.08.12 — 17:55
(4)почему?
6 — 09.08.12 — 17:56
При одновременной записи в справочник в этом случае возможно появление дублей.
7 — 09.08.12 — 17:57
Перед записью элемент справочника еще в базу не записан, поэтому второй поток не сможет выявить не уникальность реквизита.
8 — 09.08.12 — 17:58
(6)тогда при записи )
9 — 09.08.12 — 17:59
(8) Тоже неправильно)
10 — 09.08.12 — 18:01
(9)тебе не угодишь (
в типовой поиск дублей делается передЗаписью
11 — 09.08.12 — 18:04
(7)создай тогда какую нить табличку и блокируй её, или блокируй всю табл справочника
12 — 09.08.12 — 18:13
(11) Если вся эта шняга затевается для того чтобы юзеры не били контров с одинаковым ИНН и вероятность наступления одномоментного ввода элементов с одинаковым реквизитами 10 в минус ХЗ какой степени, то зачем все эти геморрои?
13 — 10.08.12 — 09:29
(11) Блокировать всю таблицу не правильно, т. к. при этом снижается производительность системы. Кроме того как это сделать?
(12) Нет, ИНН здесь ни при чем. Речь о многопотоковой параллельной работе со справочниками.
14 — 10.08.12 — 09:34
(13) регистр сведений заведите с двумя измерениями: элемент справочника и его реквизит.
15 — 10.08.12 — 09:36
А чо, ПриИзменении не подойдет?
16 — 10.08.12 — 09:37
Перед записью запросом ГДЕ МойСправочник.ИмяРеквизита = &Реквизит
17 — 10.08.12 — 09:38
(13)>>Кроме того как это сделать?
в транзакции ДЛЯ ИЗМЕНЕНИЯ, или неробит?
18 — 10.08.12 — 09:41
(7) Воспроизведи.
19 — 10.08.12 — 09:46
(18) Я должен воспроизвести? Можешь мне поверить, или проверить)
(14) Почему с 2-мя измерениями? по моему измерение должно быть одно — реквизит, проверяемый на уникальность. ну и ресурс можно сделать — ссылка на элемент справочника….
20 — 10.08.12 — 09:47
(17) ДЛЯ ИЗМЕНЕНИЯ в режиме управляемых блокировок вроде не работает
21 — 10.08.12 — 09:49
1) первая проверка:
ПередЗаписью — пробегаемся по всему справочнику
Здесь же записываем значение реквизита (которое вводится сейчас) во временный РС «ЗначенияКоторыеВводятсяСейчас»
2) вторая проверка
ПриЗаписи — смотрим РС «ЗначенияКоторыеВводятсяСейчас», нет ли там таких значений, вводимых в данный момент другими (с полной блокировкой этот регистр)
3) Периодически (тут надо подумать) чистим наш вспомогательный РС (блокируя в этот момент таблицу справочника).
Ессно, в файловой версии это работать не будет. Да и в постгри, наверное, тоже.
22 — 10.08.12 — 09:51
(19) да, с одним измерением круче, можно прямо в ПриИзменении реквизита на форме проверять.
23 — 10.08.12 — 09:55
(21) Хитрый алгоритм, насколько он оптимален с точки зрения производительности? Особенно такие моменты как «ПередЗаписью — пробегаемся по всему справочнику «…
(22) Меня больше интересует программная запись)
24 — 10.08.12 — 09:57
Насчет регистра сведений — это вы загнули. А с учетом многопользовательского режима работы — совсем уж лишнее. Пятое колесо в телеге
25 — 10.08.12 — 09:59
(24) Дело в том, что только использование регистра сведений позволяет на уровне платформы гарантированно контролировать уникальность набора измерений записи.
26 — 10.08.12 — 10:00
(24) почему? Зато уникальность сама по себе будет контролироваться. На уровне платформы. И как раз это для многопользовательской версии, для однопользовательской это не нужно.
27 — 10.08.12 — 10:07
(25) нужно еще учесть тип значения или у вас строка?
28 — 10.08.12 — 10:10
(27) Строка, длиной больше 254 символов…
29 — 10.08.12 — 10:17
(28) все-таки вводить регистр сведений для уникальности будет избыточно. Даже если открыто одновременно две формы у разных пользователей… Можно в код ПослеЗаписи поставить запрос по этому реквизиту, если выдаст более одного значения в результат, то вот и получишь поиск неуникального. Если же искать среди не записанных, в том числе и без самого себя, то гарантированного результата не достигнуть, имхо
30 — 10.08.12 — 10:19
+ имхо, потому что это все методы самой 1С. Если работать с транзакциями без 1С, то вполне допускаю мысль, что где-то они в решении такой задачи смогут помочь
31 — 10.08.12 — 10:21
(23) В любом случае понадобится таблица, хранящая все значения. Хоть тот же справочник, хоть отдельный РС (в том случае, если реквизитов в справочнике ну очень много, чтобы таблица была меньше).
Речь вообще про какие объемы? Сколько элементов в секунду будет вводиться?
32 — 10.08.12 — 10:25
(29) ПослеЗаписи, когда транзакция уже зафиксирована и данные внесены в БД, в случае не уникальности реквизита, придется удалять записанные данные, кроме того в этом случае возможна ситуация когда оба одновременно записываемых элемента (в случае 2-х конкурентных потоков) с одинаковыми реквизитами будут удалены
33 — 10.08.12 — 10:28
Чем типовое решение, с показом возможных дублей, не годится?
34 — 10.08.12 — 10:28
+ кстати, для объекта справочник события ПослеЗаписи нет)
35 — 10.08.12 — 10:30
(33) насчет типового решения не могу ничего сказать, т к не видел его
36 — 10.08.12 — 10:40
(26) Хм… на «уровне платформы»… Это об той самойплатформе речь, где функционал распределенной информационной базы встроен. Риб-база — и все ваши «навороты» для обеспечения уникальности становятся бессмысленными.
37 — 10.08.12 — 10:45
(36) В случае распределенной базы данных, да и в общем случае распределенных систем, использующих общие данные, должна быть отдельная база с так называемыми мастер-данными, для контроля уникальности и синхронизации общих элементов со всеми системами использующими эти данные.
38 — 10.08.12 — 11:20
(28) Можно подробнее, что хранится в этом реквизите?
Технически, гарантированно обеспечить уникальность реквизита при многопользовательской работе можно только двумя способами:
1) Сериализовать все изменения сущности (будь то справочник, регистр и т.д.). То есть блокировать некий общий ресурс перед записью, проверить уникальность, записать, снять блокировку. Платформа позволяет это сделать несколькими способами.
2) Ввести ограничение уникальности на уровне СУБД (unique constraint или unique index). Тут есть такие варианты:
а) хранить данные, требующие уникальности, в реквизите, для которого платформа сама создает в БД такое ограничение (например код справочника, единственное измерение РС (19));
б) создать дополнительное ограничение самостоятельно через SQL (и самому же его поддерживать, платформа о нем не знает и может его снести)
39 — 10.08.12 — 11:42
(38) Вариант 2-б мне нравится можно попробовать)
40 — 10.08.12 — 11:54
(38) Хранится строка, содержащая url-адрес.
41 — 10.08.12 — 11:57
(40) Похоже на самостоятельную сущность. Подумайте о 2а.
42 — 10.08.12 — 12:02
(41) Мне нужно получить некий идентификатор (ссылку) для дальнейшей нормальной работы с этими url-адресами. В случае использования справочника ссылка формируется автоматически при записи. В случае использования 2а, выходит что придется поддерживать 2 сущности справочник — для формирования ссылок и регистр сведений — для контроля уникальности. и делать 2 записи вместо одной…
43 — 10.08.12 — 12:17
(42) Вычислите хэш от URL и сделайте его кодом справочника (или частью кода).
44 — 10.08.12 — 12:29
(43) Он точно будет уникальным?
45 — 10.08.12 — 12:41
вот стоило бы в самом начале указать, какого характера инфу сохранять и получить совет из (43)
46 — 10.08.12 — 12:48
(45) Хэш не гарантирует уникальность
47 — 10.08.12 — 12:51
(46) md5 ?
48 — 10.08.12 — 12:54
(19) Ну вот я какбе и не верю.
49 — 10.08.12 — 13:00
50 — 10.08.12 — 13:01
целая дискуссия по поводу использования md5 хэшей в качестве примари кей. Тут не все так однозначно
51 — 10.08.12 — 13:01
(48) Проверь)
52 — 10.08.12 — 13:04
угу. это даже не задумываясь о самой задаче исключения урлов, идентичных друг другу при отсечении хвостовых пробелов
53 — 10.08.12 — 13:22
(44) Не точно. Добавьте проверку на коллизии. Можно еще один разряд добавить на случай коллизии, но я бы не стал.
(50) Не нашел там серьезных аргументов против. Кроме того, Код это не primary key.
54 — 10.08.12 — 15:30
(42)делай подчинённый справочник, код у которого твой уникальный реквизит, ессно должна быть уникальность кодов
55 — 10.08.12 — 15:41
(54) Длина кода ограничена
Defender aka LINN
56 — 11.08.12 — 10:59
(51) Вот я и говорю: воспроизведи для начала.
-
Добрый день. Имеется самописный конфиг на платформе 8.2, возможно ли настроить проверку уникальности реквизита справочника какими-нибудь встроенным способом или данная проверка осуществляется только для номера?
Вопрос №2: Насколько правильно будет писать запрос ко всем элементам справочника (не более 10 000 объектов) перед записью, с целью проверки уникальности данного реквизита, или лучше завести регистр сведений? -
Offline
TODD22
Профессионал в 1С
Команда форума- Регистрация:
- 23 фев 2009
- Сообщения:
- 5.064
- Симпатии:
- 185
- Баллы:
- 104
Во первых что это за потребность такая? Что там уникального нужно хранить?
Скорость чтения данных из таблиц не сильно зависит от того справочник или регистр сведений.
-
Online
nbIpKuH_BaH9I
Модераторы
Команда форума
Модератор- Регистрация:
- 16 сен 2009
- Сообщения:
- 8.096
- Симпатии:
- 549
- Баллы:
- 204
Ну разве что виртуальная таблица
Делайте свою проверку перед записью. Ничего страшного в этом нет. Только сильно не переусердствуйте.
-
Offline
TODD22
Профессионал в 1С
Команда форума- Регистрация:
- 23 фев 2009
- Сообщения:
- 5.064
- Симпатии:
- 185
- Баллы:
- 104
Виртуальная да… но для РС это срезы… тут вроде как про контроль уникальности речь… срезы мало чем помогут.
-
Offline
rifat
Опытный в 1С- Регистрация:
- 13 июн 2013
- Сообщения:
- 99
- Симпатии:
- 2
- Баллы:
- 29
Можно включить индексирование того реквизита справочника, по которому проверяете уникальность, если конечно это целесообразно.
-
Offline
TODD22
Профессионал в 1С
Команда форума- Регистрация:
- 23 фев 2009
- Сообщения:
- 5.064
- Симпатии:
- 185
- Баллы:
- 104
И зачем индексировать то что индексировать в принципе не нужно?
-
Offline
rifat
Опытный в 1С- Регистрация:
- 13 июн 2013
- Сообщения:
- 99
- Симпатии:
- 2
- Баллы:
- 29
Если будет производиться поиск по справочнику по этому реквизиту, разве не ускорит поиск? Если ошибаюсь поправьте.
-
Offline
TODD22
Профессионал в 1С
Команда форума- Регистрация:
- 23 фев 2009
- Сообщения:
- 5.064
- Симпатии:
- 185
- Баллы:
- 104
Может и будет производится поиск быстрее. Но прежде чем включить индексирование нужно без включенного режима посмотреть. Может скорость работы будет приемлемой и дополнительно ничего индексировать не нужно.
-
Online
nbIpKuH_BaH9I
Модераторы
Команда форума
Модератор- Регистрация:
- 16 сен 2009
- Сообщения:
- 8.096
- Симпатии:
- 549
- Баллы:
- 204
Это только усугубит ситуацию. Для создания индекса система выделяет определенные ресурсы. У справочника нет так много комбинаций полей таблицы как скажем у регистра с 10 измерениями. Так что индекс вообще здесь не нужен.
-
Offline
TODD22
Профессионал в 1С
Команда форума- Регистрация:
- 23 фев 2009
- Сообщения:
- 5.064
- Симпатии:
- 185
- Баллы:
- 104
А ещё нужно и тип реквизита знать. А то если там строка неограниченной длинны например… то индексы раздует так что потом база будет вешать неприлично много.
Как пример у меня есть база. Из за кривой структуры индексировались поля неограниченной длинны. Размер базы был более 70 Гб.
Хотя там реальных данных на 1.5 Гб. -
Всем спасибо, проверять на уникальность нужно строку 13-14 символов, буду делать через запрос к справочнику перед записью.
Элементов в справочнике будет не более 10 000, а в 99% случаев даже не более 1000, думаю можно будет справиться и без индексов. -
Offline
TODD22
Профессионал в 1С
Команда форума- Регистрация:
- 23 фев 2009
- Сообщения:
- 5.064
- Симпатии:
- 185
- Баллы:
- 104
А что на уникальность то проверяешь?
-
строку 13-14 символов, штрих-код товара
-
Offline
rshakiro
Профессионал в 1С
Команда форума- Регистрация:
- 17 мар 2011
- Сообщения:
- 2.261
- Симпатии:
- 145
- Баллы:
- 104
Обычно ШК создается на основе кода элемента справочника(который уникален)…
-
Online
nbIpKuH_BaH9I
Модераторы
Команда форума
Модератор- Регистрация:
- 16 сен 2009
- Сообщения:
- 8.096
- Симпатии:
- 549
- Баллы:
- 204
Штрихкоды хранить только в регистре сведений. Посмотрите этот механизм в любой типовой со складом. УТ например. Там прекрасно этот механизм реализован.
-
Offline
LordMaverick
Профессионал в 1С- Регистрация:
- 17 мар 2014
- Сообщения:
- 4.000
- Симпатии:
- 465
- Баллы:
- 104
не разумно, это в 7.7 его можно было ещё в реквизите справочника товара хранить
а сейчас, как уже сказали, это удобнее в РСа ещё бывают ситуации когда на одну позицию одновременно есть более одного ШК
Контроль уникальности осуществляется помощником ввода номенклатуры при вводе позиции номенклатуры. Контроль уникальности может производиться как по рабочему наименованию позиции номенклатуры, так и по любому из реквизитов, которые доступны для данного вида номенклатуры. В том числе и по дополнительным реквизитам, добавленным пользователем.
Контроль уникальности по рабочему наименованию настраивается в целом для всех позиций номенклатуры в разделе Администрирование – Номенклатура.
Контроль уникальности по отдельным реквизитам (артикул, производитель и т. д.) настраивается отдельно по каждому виду номенклатуры. В карточке вида номенклатуры показывается список тех реквизитов, которые определены для данного вида номенклатуры. В этот список включены и те дополнительные реквизиты, которые добавлены пользователем.
Необходимо отметить список тех реквизитов, по которым будет контролироваться уникальность. Для этих реквизитов автоматически устанавливается необходимость их заполнения.
Контроль уникальности производится при вводе новой позиции номенклатуры с помощью помощника ввода номенклатуры. При установке комплексного контроля по рабочему наименованию и реквизитам контроль уникальности производится поэтапно:
- уникальность реквизитов контролируется в процессе работы помощника;
- уникальность рабочего наименования контролируется при окончании работы помощника, в момент создания новой номенклатурной позиции.
Список реквизитов, которые необходимо заполнить, показывается в помощнике после указания вида номенклатуры. В списке показываются те реквизиты, для которых установлен флажок в колонке Отображать при создании (по умолчанию).
Те реквизиты, по которым контролируется уникальность, являются обязательными для заполнения и помечаются красным цветом. В эти поля необходимо ввести данные по новой позиции номенклатуры.
При контроле уникальности будут показаны те товары, у которых совпадают все указанные реквизиты. То есть в приведенном примере будут показаны те товары, у которых указан такой же артикул, тип (марка) и производитель.
Данный контроль не является жестким, пользователь может продолжить ввод новой позиции, несмотря на предупреждение (вариант Создать новую). Однако такая возможность доступна только тем пользователям, которые обладают правом ввода информации по номенклатуре без контроля. Если такого права у пользователя нет, то он не сможет ввести новую позицию номенклатуры в данной ситуации, а должен будет выбрать существующую.
Жестким является контроль по рабочему наименованию, который проводится при создании номенклатуры. Если такой контроль установлен, то ни один из пользователей не сможет создать номенклатуру с таким же наименованием.
Разработка позволяет произвольным образом настроить проверку уникальности перед записью новых элементов в ЛЮБОМ справочнике информационной базы. При этом проверка может производиться не только по реквизитам элементов, но и по значениям контактной информации.
Допустим, нам требуется обеспечить отсутствие дублей в справочнике Партнеры и Характеристики номенклатуры. Для первого справочника в качестве поля уникальности будем использовать телефон в контактных данных, а одинаковость характеристик будем проверять по сочетанию наименования и владельца.
Откроем форму настроек.
На форме настроек выводится список всех справочников, которые существуют в базе. При выделении строки с нужным справочником справа выводится справка по тем реквизитам, которые возможно использовать для контроля дублей. Нужный реквизит перенесем в колонку Реквизиты проверки.
Если реквизитов проверки несколько, перечисляем их через запятую.
Если дублями необходимо считать элементы, у которых совпадают значения всех реквизитов проверки, необходимо установить флаг Совместно. В противном случае дублями будут считаться элементы, у которых совпадает значение хотя бы одного реквизита проверки.
Теперь при записи нового (или изменении текущего) партнера программа проверяет его телефон, и если он не уникальный, то запись заканчивается ошибкой.
Сохранить характеристику с неуникальной комбинацией наименования и владельца тоже не получится.
Проверка на уникальность выполняется и при интерактивной (вызванной пользователем) и при программной (когда выполняется какой-то скрипт, без непосредственного участия пользователя) записи элементов.
Проверка на уникальность не выполняется при обмене данных между конфигурациями (когда создание/изменение элемента вызвано сторонней конфигурацией).
Для корректной работы расширения необходимо отключить Безопасный режим.
Posted On 2019-03-27
Контроль уникальности Справочника 1С
Процедура ПередЗаписью(Отказ,) Если Не Справочники.ТМЦ.НайтиПоНаименованию(Наименование) = Справочники.ТМЦ.ПустаяСсылка() Тогда Текст = "ru = ""Наименование записи справочника не уникально!"""; Предупреждение(НСтр(Текст), 10); Отказ = Истина; ЭтаФорма.Закрыть(Отказ); Возврат; КонецЕсли; КонецПроцедуры
Либо при изменении элемента формы
Процедура НаименованиеПриИзменении(Элемент) Если Не Справочники.КартыИСкидки.НайтиПоНаименованию(Наименование) = Справочники.КартыИСкидки.ПустаяСсылка() Тогда Наименование = ""; Текст = "ru = ""Наименование записи справочника не уникально!"""; Предупреждение(НСтр(Текст), 10); Отказ = Истина; // ЭтаФорма.Закрыть(Отказ); Возврат; КонецЕсли;