Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Состояние объекта и история - как лучше реализовать?

v7: Состояние объекта и история - как лучше реализовать?
Я
   Bigbro
 
04.08.20 - 09:27
Задача стоит аналогично КПП  - есть объекты, их состояние, и история - когда менялось, чтобы можно было отчет посмотреть.
как лучше реализовать с учетом того что событий много, историю надо хранить задолго, а тормоза - крайне нежелательны?
база на SQL.
периодический реквизит вызывает сомнение.
для регистра понадобится документ городить.
вспомнил про регистры сведений, но на 8ку пока не перейти)
может еще как то иначе сделать?
тут много зубров по 7ке наверняка и подобный опыт есть - поделитесь, как бы вы сделали.
   HawkEye
 
1 - 04.08.20 - 09:33
(0) ну как вариант, в течении дня пишешь в документ, в шапке Объект, в таб.части что менялось...
ночью выгружаешь в SQL, документы удаляешь или очищаешь таб.часть...
   Bigbro
 
2 - 04.08.20 - 09:36
(1) не совсем понял смысл хранения в промежуточном документе который потом удалится?
   fisher
 
3 - 04.08.20 - 09:37
Отдельная (от 1С) база и табличка. Прямые запросы.
   ADirks
 
4 - 04.08.20 - 09:37
(0) Табличку заведи. Или текстовый файл.
   fisher
 
5 - 04.08.20 - 09:37
Если в сетке видима база СКУДа, то прямо к ней запросы и строить.
   fisher
 
6 - 04.08.20 - 09:39
Если все же внутри - служебный справочник.
   Bigbro
 
7 - 04.08.20 - 09:40
(4) во что превратится текстовый файл за скажем 5 лет, и как в нем искать данные по миллионам событий? это совсем странный вариант.
(5) это не скуд, отдельная задача, просто близка очень по смыслу.
(3) это пожалуй лучший вариант пока.
   HawkEye
 
8 - 04.08.20 - 09:41
(2) чтобы в момент записи объекта не лезть в какие-то внешние соединения....
   fisher
 
9 - 04.08.20 - 09:44
Наиболее близкие по смыслу к "простой табличке" объекты что в 7.7, что в 8-ке - это справочники (не регистры сведений). В 8-ке стандартные индексируемые поля (код, наименование) удаляются выставлением длины в ноль (в 7.7 не помню - можно ли так) или их можно приспособить под нужную логику использования.
   Sserj
 
10 - 04.08.20 - 09:45
(7) Отдельная база + триггеры на запись. Триггер проверять/создавать при началеРаботыСистемы. Тогда ничего в самой 1С кроме процедурки генерации триггера и не надо будет.
   ADirks
 
11 - 04.08.20 - 09:47
(7) Запись в файл - наименее тормозной вариант.
Анализировать это добро и потом можно, много всяких инструментов есть. Да хоть бы и переписывать в SQL-табличку по ночам.
Плюс за файловый лог, это то, что в него внутри транзакции можно писать. Записи в SQL-табличку откатятся вместе с транзакцией.
   Bigbro
 
12 - 04.08.20 - 09:47
(8) звучит достаточно громоздко как в плане последующей отчетности так и потенциально проблемы записи документа если он один при конкурентных условно одновременных событиях, а если разные - тоже вопрос. но подумать в эту сторону наверное можно.
(9) в ноль можно выставить, дату время события поставить.
но потом запросом будет же всю эту кучу в миллион записей брать и фильтровать.
   fisher
 
13 - 04.08.20 - 09:48
(12) Если основной отбор будет по индексируемой дате, то размер справочника тебя особенно беспокоить не будет.
   ADirks
 
14 - 04.08.20 - 09:49
(10) У нас тут героические админы как-то раз так сделали. Это было прикольно. Хорошо их рядом не было, когда я понял, что произошло. Убил бы, ей богу.
   fisher
 
15 - 04.08.20 - 09:50
(12) Короче, если типовые запросы будут иметь приемлемую селективность по индексируемым полям, то размеры таблиц особого влияния на производительность оказывать не будут. Это как бы основная идея проектирования СУБД.
   Bigbro
 
16 - 04.08.20 - 09:51
(10) а можно чуть подробнее? с триггерами не работал.
(13) то есть добавить справочник событий с отбором по дате, событием, объектом, временем.
   fisher
 
17 - 04.08.20 - 09:51
Ну, т.е. будут конечно, но кривая будет очень пологая.
   fisher
 
18 - 04.08.20 - 09:54
(16) Вспоминая проблемы 7.7 с датой-временем, я бы их тупо зафигачил в наименование справочника в формате "ГГГГММДД ЧЧ:мм:сс"
   Bigbro
 
19 - 04.08.20 - 09:54
(17) спасибо.
если ничего более интересного не предложат, наверное так и сделаю, подводных камней особо не видно, а реализовать будет очень просто.
   ikea
 
20 - 04.08.20 - 09:56
Какое количество пользователей работает онлайн?
   HawkEye
 
21 - 04.08.20 - 09:57
(12) я же написал в шапке - "объект", а значит один объект - один документ, и ес-сно запретить его интерактивное открытие, никаких блокировок быть не должно...
я бы (скорее всего) просто добавил ко всем объектам по которым надо хранить историю реквизит - документ.История и создавал его вместе с объектом, дальше при записи объекта писал уже в готовый документ только измененные реквизиты...

ночью эти данные переносил в базу SQL с очисткой таб.части

Отчеты строить по умолчанию - по данным SQL базы (или в зависимости от периода отчета)...
   ikea
 
22 - 04.08.20 - 10:00
Тригеры не вариант - нужно будет постоянно следить за добавление/изменением/удалением реквизитов.
Поскольку база SQL - оптимальный вариант - хранение в справочниках истории.
   Bigbro
 
23 - 04.08.20 - 10:01
(20) 30+/- плюс всяческие регламентные обмены.
   ikea
 
24 - 04.08.20 - 10:02
С прямыми запросами как?
   Bigbro
 
25 - 04.08.20 - 10:03
(24) когда-то пробовал, понравилось, но на этой базе живем пока без них.
если начнется засада с быстродействием начну переводить самые тонкие места.
   Ёпрст
 
26 - 04.08.20 - 10:04
делал когда то, хранил в отдельной табличке
http://pics.rsh.ru/img/_htgo09q3.png
   HawkEye
 
27 - 04.08.20 - 10:04
+21 почему не справочник....
1. получить изменения по объекту можно просто выгрузить в ТЗ таб.часть документа, который указан в реквизите vs ВыбратьЭлементыПоРеквизиту и цикл с заполнением...
2. удаление истории: очистка таб.части vs цикл по элементам справочника с непосредственным удалением...

и т.д.
   Ёпрст
 
28 - 04.08.20 - 10:07
а в снеговике, иногда не хватает вот этого
http://catalog.mista.ru/public/20038/
   Kigo_Kigo
 
29 - 04.08.20 - 10:10
Помню когда то заморачивался с подобным, как реализовывал не помню, помню одно, вся заварушка была из-за одного случая, гемора принесла много в последствии не потребовалась, потому как настроил такой импровизированный СКУД уже с записью прямо в док кем когда и скаой целью редактируется док, слава богу только до номенклатуры только добрались, да и доки токак приход расход(сф)
   ikea
 
30 - 04.08.20 - 10:12
1. Чтобы избежать конфликта блокировок при одновременной записи изменений разными пользователями - пиши изменения в текстовый файл с генерацией уникального имени в файл. Ночью файлы обрабатывай и пиши в справочник с последующим удалением обработанных файлов.
2. Я делал два справочника - один просто как таблица - Дата|Время|Пользователь|ТипОбъекта|ВидОбъекта|ИзменениеОбъекта(Справочник), второй справочник - ИзменениеОбъекта, где уже хранится история изменения объекта.
 
 Рекламное место пустует
   fisher
 
31 - 04.08.20 - 10:12
(28) Почему не хватает? Версионирование же?
   HawkEye
 
32 - 04.08.20 - 10:13
(29) во всех критических объектах всегда делаю реквизиты Автор, ДатаСоздания, Редактор, ДатаРедактирования...
и все говорю: последний записал - принял на себя все риски по содержимому ))
   fisher
 
33 - 04.08.20 - 10:13
(28) А, сорри. Невнимателен.
   fisher
 
34 - 04.08.20 - 10:15
(28) Но по-идее, реализовать же можно и значительно проще, чем в 7.7
   Bigbro
 
35 - 04.08.20 - 10:17
(26) что насчет справочника с историей состояния скажешь, с отбором на дату? то что фишер советует?
   Ёпрст
 
36 - 04.08.20 - 10:18
(34) ну..как то лень пересиливает.
Надо будет заняться что, ле на досуге.
Иногда полезно:

к примеру, в большом доке удаляешь что-то с таб части и ошибся, всё привет, выходи без сохранения и всё по-новой. А так, была бы отмена действий, вплоть до первоначального состояния.
   Kigo_Kigo
 
37 - 04.08.20 - 10:19
(32) Примерно так, так и было - кто последний тот и папа, но они еще писали пояснение -зачем они туда лезут для редактирования, а вот если пояснения не было - сразу депримирование, еще  помню делали большой пул для копий БД, откуда можно было сравнить изменения
   Ёпрст
 
38 - 04.08.20 - 10:19
(35) да пофик где хранить то, хоть тупо строка и значениВСтроку\ЗначениеВСтрокуВнутр..
   Ёпрст
 
39 - 04.08.20 - 10:22
Как показала практика, особа вся эта инфа с версионированием (что в 7.7, что в снеговике) особо то и не нужна, ну так, информации для.
Ну выяснили , что месяц назад где-то кто-то что-то изменил ..дальше то что ? Поезд ушел :)
Если только не явная диверсия, то, на эту инфу можно забить.
Единственное, если в один документ вносят изменения несколько юзверей на разных этапах, добавляя в него новую инфу, можно посмотреть цепочку редактирований..усё
   Ёпрст
 
40 - 04.08.20 - 10:24
В снеговике, частая операция в обслуживании базы - прибитие устаревшей инфы в регистре версииобъектов, чтоб не пух :)
   Ёпрст
 
41 - 04.08.20 - 10:24
Ибо смотреть, что там было полгода назад, никто уже не будет
   Bigbro
 
42 - 04.08.20 - 10:26
(41) у меня к сожалению смотреть будут и на то что было 3 года назад тоже)
   Bigbro
 
43 - 04.08.20 - 10:28
ладно всем спасибо за участие сделаю на справочнике. можно прикрыть.


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.