gifts2017

Приложение к публикации: "Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL. "(с)

Опубликовал Владимир (hogik) в раздел Администрирование - Оптимизация БД (HighLoad)

Основная статья находится по адресу: http://infostart.ru/public/94040/

 

В основной статье выдвигается тезис, что свёртка базы данных (БД) делается только из-за размера БД. Позволю себе не согласиться с автором.

 

Но, полностью соглашусь с утверждением автора основной статьи:

"В современных условиях очень странно бывает иногда слышать "нам нужно свернуть БД 1С - её объём превышает 50 ГБ"."(с)

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

Схема БД продуктов "1С:Предприятие" ориентирована на решение учетных/отчетных задач (УОЗ).

Для задач такой направленности характерно:

1) Использование в качестве исходной информации бумажный (первичный) документ. Как на "входе" системы, так и на "выходе".

2) Цикличность накопления и обработки информации.

Т.е. применимы такие понятия, как: закрыть/открыть период, входящие/исходящие итоги, пересчитать итоги, архивирование "первичной" информации, итоговый (балансовый) отчет за фиксированные периоды, итоги на дату, последовательности документов (пачки) и т.д.

Т.е. в таких ИС моделируется УОЗ и вся схема базы данных "заточена", именно, на решение подобных задач. Т.е. отражается "житейское" представление человека в "кишках" информационной системы практически без изменения.

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

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

Но, развитие информационных систем идет в сторону накопления и обработки наиболее полной (интегрированной) информации о деятельности людей. А полнота подразумевает как долгосрочность хранения так и отсутствие фиксированной периодичной обработки и анализа информации. Т.е. места для такого понятия как "свертка БД" - НЕТУ.

Возникает "конфликт" между концепцией (архитектурой) платформ "1С:Предприятие" (всех версий) и задачами которые на неё возлагается.

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

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

Но, внешне, ничего плохого нету. Ведь, пользователь редко обращается к старой информации. А, информация в регистрах лежит в хронологическом порядке. Да, сама информация - в хронологическом. Но, регистр - это таблица БД с индексом по измерениям. Допустим, что СУБД строит индекс в виде "B-дерева". Это означает, что записи регистра в индексной структуре будут представлены не в хронологическом порядке, а в "смысловой". И если система не обращается к "старым" записям таблицы регистров (и документам их порождающим) то "сталкиваться" с ключами индекса регистров от "старых" записей, ей придется.

Мне неловко приводить собственное описание способов представления и обработки "индексных структур" в СУБД, т.к. ... Но, к этим описаниям имеет смысл добавить, что любые действия с деревьями требуют использования "технологических" блокировок. Как при записи, так и при чтении записей таблицы в порядке индекса. Т.е. если обрабатывается регистр в порядке индекса с ключом: "Товар+...+....", то будет приостановлена работа (условно говоря) со всеми документами, отчетами и т.д. использующими одинаковое значение "Товар". А время заблокированного состояния зависит от "глубины и ветвистости" дерева. Которое, в свою очередь, зависит от количества записей таблицы и от "характера значений" ключей. Могут возникать, условно говоря, и конфликт блокировок (deadlock).

Но, в области СУБД-строения и ЭВМ-строения с этими "проблемами" борются. Разными способами, и с переменным успехом. Но, думаю, гораздо большего успеха в этой борьбе можно добиться разработкой схемы базы данных отвечающей не только УОЗ проблематике, но и более общим задачам АСУПа.

Возвращаясь к основной статье, приведу из неё цитату:

"Если бы такое собирались сделать администраторы систем SAP R3 или Oracle e Business Suite или даже MS Dynamics Ax их бы наверное уволили."(с)

Похоже на правду. Только причина не указана - почему не приходит в голову свертывать базы данных в этих системах. А причина, думаю, простая. Эти системы не ориентированы только на УОЗ в сути своей архитектуры.

См. также

Подписаться Добавить вознаграждение

Комментарии

0. Владимир (hogik) 14.10.11 17:25
1. Олег Филиппов (comol) 14.10.11 17:25
И всё было бы хорошо, кроме одного - таблица для хранения регистров имеет суммарное количество записей по всем видам документов "входящих" в регистр.
Нужно писать - для 1С 7.7
2. Олег Филиппов (comol) 14.10.11 17:29
СУБД-строения и ЭВМ-строени
:cry:
4. Александр Капустин (kapustinag) 14.10.11 22:36
Может быть, можно придраться к отдельным словам или фразам статьи, но с основной мыслью автора полностью согласен. Насколько легче было бы жить, если бы журналы документов и регистры допускали секционирование или вынесение старых данных в архив! Не путем допиливания конфигурации, а как штатная возможность платформы.

Да, если используем Microsoft SQL-сервер Enterprize Edition, секционирование таблиц можно сделать средствами SQL-сервера. Но это придется делать вручную для каждой такой таблицы, и заботиться, не случится ли что при обновлениях и т.п.
Вспомним, как работал бухгалтер без компьютера: он, в частности, вел журналы документов в специальных тетрадях. А заполненные тетради складывал в папки по годам. У него всегда под рукой был архив журналов за весь период, в течение которого законодательством предписывалось хранить журналы. Но этот архив не мешал ему делать текущую работу.
А разработчики большинства программ, ориентированных на "решение учетно/отчетных задач", положившись на безграничные мощность процессора, объем памяти и диска, решили, что архивы, неотделенные от текущих данных, не будут мешать эти текущие данные обрабатывать. Это ошибка, я считаю.
5. Владимир (hogik) 14.10.11 23:42
(4)
Александр (kapustinag).
Если рассуждать от достигнутого, что - есть объект АвтоМехАнизации под название "Документ", то - да. Суть "секционирование таблиц" можно (и желательно) "вставлять" в платформу.
Но, я в своей статейке пытаюсь, еще продвинуть "мысль", что не документами описывается предметная область. Хотя, это и мало отношения имеет к текущей версии 1С-ов.
Но, думаю, огромную роль в провалах внедрения АСУП-ных систем играет попытка превратить ВСЁ предприятие в огромную "бухгалтерию" по сбору документов. И жить по правилам "бухгалтерии". Нет в реальной жизни никаких журналов документов и регистров. Для "образования" этих понятий в том месте, где они действительно используются (учет) - уже достаточно технических средств "сбора" информации из тех точек "бизнес процессов" где она возникает. Т.е. не документ имеет движение, а - материальная ценность и деньги двигаются между точками их применения. ;-) Очень хорошо это укладывается в сетевую (иерархическую, объектную) модель баз данных. И многие вопрос уходят на второй план. Например, такие как: блокировки, размеры БД, искусственное преобразование структур данных туды-сюды, модульность подсистем, интеграция данных, постепенное внедрение, "паразитные" структуры данных типа - регистр и т.д.
6. Александр Рытов (Арчибальд) 17.10.11 08:17
(2) Противник словесности?
7. Александр Рытов (Арчибальд) 17.10.11 09:10
Вообще говоря, статья не о СУБД, конечно, а о жизни. Точнее, об отражении жизненных реалий техническими средствами. О том, что техника отображения (моделирования) зависит от текущих потребностей "моделиста". И на самом деле, по модели можно судить не только (и даже не столько) об объекте моделирования, но и о субъекте.
Вспомним, откуда взялась (выросла) 1С. Расплодившимся в конце 80-х мелким лавочникам потребовалось средство, чтобы отбиваться от государственного рэкета, в котором, в отличие от рэкета криминального, размер платежей исчисляется, исходя не из реального финансового состояния, а из документально оформленного. Именно поэтому "Документ" стал "священной коровой" одноэсных продуктов.
Надо сказать, что в этом то ли 1С попала "в струю", то ли тенденции автоматизации бизнеса попали под влияние 1С - так или иначе, за что ни возьмись - вместо реалий упираешься в документооборот. Примеров тому великое множество, приведу один модный термин: бизнес-процесс. Копни его - и увидишь, что это не что иное, как документооборот, сопровождающий некий хозяйственный цикл.
Другой пример "повернутости" на документы в противовес реалиям. При анкетировании в рамках исследования должностей я указал в качестве своей функции "формирование и реализация технической политики предприятия в сфере компьютеризации учета". И сразу же получил вопрос от анкетирующих о существовании документа с нименованием "техническая политика предприятия". А его как раз и не существует - но политика-то есть! Выходит, цель анкетирования - не описание должности, а описание входящих/исходящих документов...
Мое глубокое убеждение - документооборот (и Документооборот в смысле 1С) описывает жизнь не просто некорректно, а извращенно с особым цинизмом. Под чем и подписуюсь.
fzt; CheBurator; vkr; leoner61; Evgen.Ponomarenko; Rustig; AlexO; maxpiter; comol; cool.vlad4; +10 Ответить 2
8. Ийон Тихий (cool.vlad4) 17.10.11 10:43
(7) ага, а потом появляются такие статьи http://infostart.ru/public/93587/
9. Сергей (ildarovich) 17.10.11 17:14
Интересная тема:
1) Кажется, не стоит противопоставлять концепции построения АСУП и конкретные технические решения для конкретной СУБД. - Это совершенно разный уровень проблем. О чем тут спорить? Практикам интересны конкретные технические решения, применимые здесь и сейчас, для конкретной версии 1С. Есть плюсы (быстродействие) и минусы (надежность), - прием не бесспорный, это очевидно. Зато читатели узнали о спектре возможностей настройки СУБД. За это знание и плюсы в статье;
2) Теперь о концепции построения АСУП. - Сколько их уже было! СУБД - это инструмент хранения. Сетевая, иерархическая, реляционная - какая разница? У АСУП должна быть более глубокая парадигма. 1С доказала устойчивость своей парадигмы и менять ее не собирается. А зачем? В чем проблемы? Не нравится слово "документ"?
Кстати, у западных систем, по-моему, вообще еще меньше стройности и концептуальности. Там нет крупных кирпичиков - почти что одни таблицы. Гибкости при разработке больше, а трудность и цена кастомизации выше.
В общем, предлагайте парадигму вместо "документ". Иначе критика выглядит неконструктивной.
Dolly_EV; Rustig; +2 Ответить 1
10. Владимир (hogik) 17.10.11 19:08
(9)
Сергей (ildarovich).
1) "не стоит противопоставлять концепции построения АСУП и конкретные технические решения для конкретной СУБД"(с)
Согласен. Но между СУБД и АСУП существует мАААА-аленькая "прослойка" - схема базы данных. ;-) И эта "прослойка" разрабатывается с учетом потребностей АСУПа и технических возможностей СУБД.
2) "Это совершенно разный уровень проблем."(с)
Ошибаетесь. Уровень, то - разный. Но, работать ОНО должно совместно.
3) "Практикам интересны конкретные технические решения, применимые здесь и сейчас, для конкретной версии 1С."(с)
Согласен.
4) "Есть плюсы (быстродействие) и минусы (надежность),"(с)
Т.е. можно складывать килограммы и метры? ;-)
5) "прием не бесспорный, это очевидно"(с)
В "основной" статье рассматриваются (противопоставляются) "объемы" и "надежность", а используется средство для повышения скорости. Хотя, с самого начала указывается, что в современном мире с расширением "объемов" нет проблем. Главное отвертку вовремя наточить... ;-)
6) "За это знание и плюсы в статье;"(с)
Допускаю. Но, знания имеет смысл применять по назначению. И, лично я, долго пытался призвать автора "основной" статьи к осознанию этого. Не получилось... :-(
7) "Сколько их уже было! СУБД - это инструмент хранения. Сетевая, иерархическая, реляционная - какая разница?"(с)
Их было очень мало. Сами, же перечислили почти все. ;-) Но, не осознавать их разницу и влияние на "прослойку"... Не ожидал такого вывода... :-(
8) "У АСУП должна быть более глубокая парадигма."(с)
Согласен.
9) "1С доказала устойчивость своей парадигмы и менять ее не собирается."(с)
В смысле сбыта своего продукта - да. А в смысле постоянного (постепенного) понимания той самой "парадигмы" - нет. Одной фразой, развитие 1С-продуктов можно охарактеризовать, как: "попытка уложить иерархическую модель в реляционную".
10) "А зачем? В чем проблемы? Не нравится слово "документ"?"(с)
Это точно. :-) На грани с цинизмом. :-(
11) "Кстати, у западных систем, по-моему, вообще еще меньше стройности и концептуальности."(с)
В ИХ системах проведена четкая грань (уровень) где, далее (выше/ближе к предметной области), "стройность и концептуальность" - НЕВОЗМОЖНА.
12) "Там нет крупных кирпичиков - почти что одни таблицы."(с)
Да - нет крупных кирпичиков. Т.е. как и при строительстве зданий. Из больших блоков можно построить только Хрущебу. ;-)
13) "Гибкости при разработке больше, а трудность и цена кастомизации выше"(с)
Естественно.
14) "В общем, предлагайте парадигму вместо "документ". Иначе критика выглядит неконструктивной."(с)
Нет, с моей стороны, никакой критики. Печаль одна... :-( Какая может быть парадигма вместо "документа", если ставится задача (цель) - сбор документов. Поменяется "задача" - поменяется и "парадигма". А пока, системы ориентированные не на "пАчкование документов" умирают. А "парадигма от документа" живет уже, почти полвека... :-( :-( :-( Но, с точки зрения реляционной модели БД и предметной области (пусть, даже ставится задача - собирать документы в пачки) - хранить документ как "монолитную" структуру - не разумно. Вспомните про "Графины"... ;-)
11. Роман Романов (romansun) 17.10.11 19:43
появилось много статей на темы всяких ERP-APS, но не пойму в целом, а чего все спорят, поэтому не могу корректно "влезть" в перепалку :)

но тем не менее

hogik пишет:
Но, думаю, огромную роль в провалах внедрения АСУП-ных систем играет попытка превратить ВСЁ предприятие в огромную "бухгалтерию" по сбору документов.


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

Проблемы начинаются, когда:

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

- и из всего этого вытекает еще более глобальная проблема - высшему руководству часто тупо наплевать на всё это, ему не нужна эта 1С в компьютере, оно не готово заниматься каким-то планированием, анализом, смотреть какие-то графики и пр. Там всё распилено, цены на продукцию уже обозначены заранее и строго секретны, там мерседесы и порше и т.д. и т.п.

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

P.S. после n лет разработки и внедрения была как-то презентация отчета, считающего себестоимость изделия, финдиректору. Слушал молча, внимательно, нахмурившись. После подробного рассказа и показа общего листа отчета тыкает в цифры стоимостей и спрашивает:
- всё ок, но кто вот бьёт эти цифры?
- ээээ... никто не бьёт... программа сама посчитала, мы же вот тут вам рассказали..
- не, это я понял, но вот тут, например, литье - столько-то рублей, материалы - столько-то. Вот кто забивает эти цифры в систему?
- да никто не забивает, программа сама считает, начиная с каждого болтика, шайбочки и детальки..
- как так?? Не морочте мне голову!! Как так у вас всё считается?? Этим цифрам нельзя доверять..

и т.д.
Rustig; e.kogan; +2 Ответить 1
12. Сергей (ildarovich) 17.10.11 20:47
(7)(10) Про "Документ": Как всегда, чем короче слово, тем шире понятие и возможности неоднозначной интерпретации. Мне кажется, что понимать "документ" следует так:
Есть предприятие как система. Ее состояние определяется набором параметров. В определенное время состояние меняется (приходят деньги на расчетный счет, отгружается товар, регистрируется выпуск продукции, списываются материалы на выпуск, проходят через проходную сотрудники). Во многих случаях длительность самого изменения невелика или несущественна, поэтому его можно считать "мгновенным". Это изменение регистрируется в системе. Для этого вручную (или автоматически) формируется объект в базе данных с параметрами, характеризующими время изменения и его характеристики. Этот объект "проводится", то есть записывается так, что меняются параметры системы (ресурсы регистров) и определен факт изменения.
Это очень широкая концепция, позволяющая моделировать очень многие процессы. Чем Вы предлагаете заменить документ-событие?
Предложите! Можете назвать сети Петри, конечные автоматы, сетевые графики, блок-схемы, таблицы решений, структурные схемы, иерархические схемы, фреймы и прочее. Что Вам больше нравится, что шире, удобнее, выразительнее? Модель должна иметь стержень, ключевую метафору. А иначе получите "действующую модель паровоза в натуральную величину". ООП + паттерны? Попробуйте пофантазировать! А так получается, что "что-то другое, а не документ", но что именно?
CheBurator; maxpiter; romansun; +3 Ответить 3
13. Владимир (hogik) 17.10.11 21:25
(11)
Роман (romansun).
Всё верно Вы написали.
Только:
1) Не "ERP-APS",а "ERP+APS" мы пытаемся делать.
2) И кода "необходимо влить в общий информационный поток", то это не означает "серьёзные изменения бизнес-процессов"(с).
Системы (задачи, функции, алгоритмы т.д.) не складываются. Они могут лишь "встраиваться" (интегрироваться) и базироваться на нечто общем. Это общее - исходные данные общие для всех задач. Для успешного встраивания должна проводится четкая систематизации информации без привязки (но с учетом) к алгоритмам последующего их использования. И чем больше в исходных данных присутствует элементов направленных на решение конкретной (частной) задачи тем меньше шансов (и сложнее) обобщить другие задачи.
Для такого подхода в построении ИС и придуманы "БнД=БД+СУБД+Администрирование".(очень давно придумали!!!). С очень важным дополнением - описание схемы базы данных должна быть открытой и общей для всех задач имеющих отношение к хранимой (и собираемой) информации в базе данных.
Ну и лозунг должен быть, примерно, таким: ;-)
"Оставить бизнес-процессы организации без изменений, настроив под них нашу систему.
Разместить бизнес-решение там, где вам удобно: внутри компании или у хостинг-партнера.
Выбрать модель внедрения, оптимальную по сочетанию рисков, затрат, сроков и ресурсов."(с) http://www.microsoft.com/rus/dynamics/about/overview.mspx

Продукты от 1С не соответствуют принципам построения БнД и не могут служит платформой для АСУПа. Вот, так грубо скажу...
14. Владимир (hogik) 17.10.11 21:33
(12)
Сергей.
Ваше сообщение адресовано двум собеседникам.
Я подожду ответа от Другого Вашего собеседника. ;-)
Лады?
15. Роман Романов (romansun) 17.10.11 21:55
hogik пишет:
Ну и лозунг должен быть, примерно, таким: ;-)
"Оставить бизнес-процессы организации без изменений, настроив под них нашу систему.


Круто конечно и, наверное, правильно... Только нереально )) Почему? Потому как часто на предприятиях, схему работы которых придумывали и внедряли в 70-80гг всякие НИИ - за прошедшее время часто 2+2=5, а 2*3=7, а операция деления вообще отменена еще при старом режиме директоре.

Там почти что априори приходится выправлять и 2+2 и 2*3, иначе просто код не пишется.

Может и не на всех так, но где я имел возможность работать - было и есть так.

А вот изначальные схемы и бизнес-процессы были круты, да! Но изменились с тех пор до неузнаваемости, как в кривых зеркалах.
16. Роман Романов (romansun) 17.10.11 22:13
(12) согласен, +1

хоть сети Петри (услышал знакомое институтское слово), хоть графы - всё равно событийная модель на основе таблиц.

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

--------

На мой взгляд, про документоориентированность 1С стоит говорить в том контексте, что весь 1С-учет (бухучет, в частности) у нас часто построен не для отражения реальных ситуаций на предприятии, а тупо для сдачи отчетностей. В отличии, кстати, от западного софта. Поэтому у нас можно ковыряться в закрытых периодах (а как же?? мне ведь надо чтоб в нонешних цифрах всё сошлось), а в западных - нет (позвольте, зачем вам править в прошлых данных, у вас же поплывут настоящие цифры и вы не увидите своих косяков???)

И всё это, опять же, упирается в людей. Стройную и прозрачную схему работы в реале можно и в экселе автоматизировать - работать будет только в путь. В противном случае, никакие системы, методики и теории не помогают, к сожалению.
17. Владимир (hogik) 17.10.11 22:16
(15)
Роман (romansun).
Согласен. И лозунг привел специально. ;-)
Я же не первый десяток лет в АСУПе. :-(
Но 2+2=5 это не бизнес процесс. Это его отсутствие.
Ну, а дальше классика...
Надо научить людей пользоваться пипкми компьютера и обеспечить ему продвинутую пишущую машинку с калькулятором. И это уже очень много! А если бумажные документы не будут теряться пачками - отлично. Только, тогда давайте не будем говорить о всяких названиях из трех букв.
Помню, как много лет назад делили машинное время между пользователями при использовании нашего аналога IBM/370. Все бегали с собственными дисками с персональной операционной системой и в каждой лаборатории занимались разработкой собственно банка данных под управлением личной СУБД.
Потом появились персональные ЭВМ. Рассосалось. Разбежались по углам. Машинное время перестали делить со скандалами. И тут от НИХ приползла зараза - сети... И опять, по кругу...
Ну чего сказать? Да, 2+2=5... :-)
18. Владимир (hogik) 17.10.11 22:23
(16)
Роман (romansun).
Вы написали: "что весь 1С-учет (бухучет, в частности)"(с)
Стоп!
А АвтоМехАнизация - это только учет?
Тогда и разговора нету.
Начинаем перечитывать мою статейку и комментарии темы заново.
19. Владимир (hogik) 18.10.11 01:50
(15)
Роман (romansun).
Эх. Понесло меня на примитивные тексты... :-)
Извините.
Химия. НИИ. Все проводят исследования, анализы, утилизацию реактивов и т.д.
Ну, сделайте сначала, чтобы потребитель реактива мог на "компьютере" выбрать, набрать, заказать необходимые ему реактивы (материалы) для своей работы. Наращивайте описание реактивов, для более качественного выбора. Он же после проведения этапа своей работы делает отчет по затратам этих реактивов по отношению к заказчику (другой лаборатории). Пусть забьёт это в "компьютер". И не в виде "требование на" (и др. т.н. документов), а в понятной ему форме. Его не волнует ни склад, ни НДС. Может в другой лаборатории есть эти реактивы. И покупать не надо. И ждать не надо. Для этого - что? Бизнес процессы ломать придется. Или там есть корпоративные секреты. Воровство спирта - есть. Но это ни для кого, не секрет...
И надо обеспечить достоверность информации (пусть - малой), и доступ к этому компьютеру в режиме 24/7. Без всяких сверток БД и регламентных работ. Иначе, отвратите, изначально, человека от использования эТТого устройства. Компьютер должен помогать пользователю, а не добавлять ему лишнюю работу. Только тогда пользователь будет на Вашей (ИТ-шной) стороне.
Нет, блин, нам сразу подавай систему с названием из трех букв. Покупную, готовую обязательно. И чтобы всё делала сама. Прибыль считала и графики строила. А цифирь мы возьмем из бухгалтерии, т.к. только там достоверная информация. А чтобы она была полная и оперативная - наладим "УУ". Рядышком, чтобы пачки документов далеко не носить от одного компьютера к другому. Типа, механизация труда бухгалтера в вопросе перенося тяжестей...
Ну, сделайте чтобы на складе не наклеивали "собственные" штрих-коды, если "внешние" нормальные (уникальные). Сделайте базу данных разных наименований одного товара для быстрого приема. Или чтобы продавец не мог пробить один товар (дешевый), а выдать (своему другу-покупателю) дорогой. Чтобы остатки на складе сходились не по б.учету на конец прошлого квартала, а на сейчас, когда за товаром приходит оптовый покупатель. И сделайте это не бесконечными обменами между системами с названием из трех букв, а "автоматически" - в одной базе данных. В реальном масштабе времени жизни, а не бухгалтерии.
Может тогда и прибыль будет не только посчитана, но и, просто - будет.
А если Ваш начальник этого не понимает (а Вы - понимаете), то надо сменить начальника.
Для этого есть два способа...
20. Александр Рытов (Арчибальд) 18.10.11 11:43
(12)
Это очень широкая концепция, позволяющая моделировать очень многие процессы. Чем Вы предлагаете заменить документ-событие?
Двумя руками за! Если документ = событие - все нормально. Однако во-первых, в 1С время документа не совпадает с временем события - это породило гемор с "восстановлением последовательности". Во-вторых, одним документом могут быть зафиксированы два (и более) событития - скажем, факт выписки (продажи) товара и его отгрузки. В-третьих, при проведении (изменении состояния модели предприятия) зачастую результат зависит от момента проведения. Тут уж сплошные парадоксы времени получаются из научной фантастики. В жизни такого не бывает, т.е. концепция (модель), основанная на 1С-Документе нежизненна. Как мне показалось, статья именно об этом...
CheBurator; hogik; cool.vlad4; +3 Ответить 2
21. Сергей (ildarovich) 18.10.11 15:48
(20) Во-первых, во-вторых и в-третьих решается простым способом - полным запретом проведения документов задним числом. То есть все, что перечислено - не недостатки модели и концепции, а практики ее применения. То есть Вы говорите - модель "нежизненна". Следует ли понимать так, что жизненная модель должна разрешать помещать в базу данных любые факты, в любом порядке, за любые периоды и сама определять их достоверность и согласованность. Или все же быть своего рода тотальным (видео)регистратором - работать в реальном времени. Я не спорю - я спрашиваю: не встречалось ли Вам удачных идей, концепций, моделей, которые могли бы лечь в основу "хорошей" системы, если 1С такая "плохая" и основанная на порочной концепции система. Что можно в принципе противопоставить подходу 1С? Какой правильный стержень?
Моя мысль в том, что критика бессмысленна в отсутствии более-менее конкретных представлений об идеальной системе. Ведь для управления нужна цель, направление. Здесь, предположим, плохо. Но куда Вы предлагаете двигаться?
CheBurator; ljubasia; +2 Ответить 1
22. Владимир (hogik) 18.10.11 23:05
(21)
Сергей (ildarovich).
Я подписываюсь под (20) сообщением.
1) А вот Ваше: "Во-первых, во-вторых и в-третьих решается простым способом - полным запретом проведения документов задним числом."(с) вызывает у меня удивление.
Возможно, приведу не очень удачный пример, но... Просто, очень много таких примеров. Я, даже, теряюсь приводить совсем уж конкретные примеры.
Например, существуют документы от даты которого исчисляется время возможности его использования. А момент конкретного его использования (совершения ХО) фиксируется другой датой. Например, подписями с датой, сторон совершающих ХО. Т.е. одна дата на документе это очень "большое" допущение в вопросе отражения реальных ХО. И если подобный документ заносится в БД, то либо надо иметь возможность изменять его задним числом, либо вносить задним числом сам документ. А по какой дате...? Или подобные документы не надо заносить в БД?
2) "которые могли бы лечь в основу "хорошей" системы"(с)
На данный момент моего понимания, мне представляется "идеальной" моделью системы, где существует возможность "называть" объектами реальные объекты нашей жизни. Т.е. например, товар (объект) осуществляет собственное "движение" между объектами хозяйственной деятельности. А не объект-документ порождает своё движение на регистрах учета ;-)
Из реально существующей системы для АСУПа (не в области СУБД - там одна, всем известная) - это "ABACUS Financial (AF7)" в сути её "ABACUS Builder (AB7)". Тут: http://www.omega.ru/ab.html есть, разбросанные по тексту, файлы PDF. Гляньте их содержание. Обратите внимание на год создания этого продукта. ;-)
У меня есть много критики в адрес этого продукта. Но, так красиво уложиться в "SQL-ную" СУБД - это достойно изучения. И запросы там, почти, по делу...
3) "Ведь для управления нужна цель, направление."(с)
Для управления нужен объект управления. И полные, достоверные, точные данные (информация) о состоянии этого объекта. Этим, в первую очередь, и должна заниматься АСУП-ина. ;-)
4) Сергей. Я ужо обмолвился, выше по тексту, про "Графины". Вас не заинтересовала тема - "раздолбать" модель (архитектуру) 1С-продукта "графинами"?
23. Сергей (ildarovich) 19.10.11 17:36
(22)
1) В "тяжелых" случаях документов может быть несколько. Они будут объединены структурой подчиненности. То есть одному печатному документу будет соответствовать несколько модельных документов. А еще есть "стадии" (УТ11), бизнес-процессы. В 8-ке очень много и других готовых объектов.
2) Посмотрю ссылки, спасибо. Идея с объектами, осуществляющими "движения", наверное, правильная. Кажется, разработчики WMS на базе 1С идут по этому пути.
3) Под целью я понимал описание идеальной системы. Вы его дали в п.2.
4) Про "графины" ничего не понял. Наверное, что-то пропустил.
24. Владимир (hogik) 19.10.11 18:47
(23)
Сергей (ildarovich).
1) Можно углубиться (вернуться) к теме "первичный документ". ;-)
Уже обсуждали на данном ресурсе.
Но, например:
"Документ есть закодированное определенным образом и зафиксированное на специальном носителе информационное сообщение (свидетельство), удостоверяющее, что факт хозяйственной жизни или существует, или совершен, или должен быть совершен.
...
Первичные бухгалтерские документы — письменное свидетельство о совершенной хозяйственной операции или дающее право на ее совершение."(с)
[ http://www.r-ooo.ru/byx_obsluzyvanie.php?pid=31 ]

В описании "Управление производственным предприятием"(УПП) от 1С есть текст:
"Средством регистрации хозяйственной операции является документ, причем для ускорения работы широко используются механизмы подстановки данных "по умолчанию", ввод новых документов на основании ранее введенных. "(с)
[ http://v8.1c.ru/enterprise/ ]

Я, из этих определений, делаю однозначный вывод: "В УПП АвтоМехАнизируется учет документов.". И в 1С-продуктах всё сделано хорошо для ЭТОЙ задачи. Гораздо лучше чем полвека назад. Но суть не изменилась. :-( Изменилась только "внешняя" форма. :-(

2) Интересно, сколько "готовых объектов"(с) будет использоваться в подобных задачах? :-)

3) Я - молодец. :-)

4) Тогда - забудем :-(
25. pvase (pvase) 08.08.12 11:07
Есть несколько нерешенных проблем:
1 - Если база 7.7 - то все немного не так, Большой обьъем данных может быть не в таблицах RG а в RA, и если не включена бістрая обработка движений (нет поля DATE_TIME_IDDOC), то разделить на группы по полю - нет возможности.
2 - Если база растет, то любые изменения в структуре вызывает пересчет данных по измененным таблицам, что при росте БД может вырости в разы. Так добавление новой графы отбора может привести к серьезным пересчетам. Или же удаление реквизита и поиск ссылок (это в 7.7).
3 - Бекапы базы, их ведь надо хранить и если размер не 10 ГБ а 100, то даже при зжатии бекапа надо очень большое хранилище чтобы каждый день хранить полный бекап, хотя бы за пару месяцев.

Так что в предложенном автором механизме реализации есть как плюсы так и минусы, и каждый должен принимать решение исходя из своих соображений и свой ситуации, потому что не может быть здесь одного универсального решения.
26. Алекс Ю (AlexO) 08.08.12 11:45
(25) pvase,
Причем тут 7.7? Тут речь идет об основах построения БД 1С8 - концепции и насколько она оправдана.
А не хранения таблиц документов в SQL в 7.7.
27. pvase (pvase) 08.08.12 12:02
(26) AlexO, Извините, из статьи не видно что речь идет исключительно об 8-ке. Напротив речь идет об свертке базы 1С и зачем это делать.
А концепция построения БД в 1С 8 - это немного другая тема, и в заголовке статьи и в самой статье об этом не нашел упоминания.
И поскольку все манипуляции производятся на SQL Server минуя 1С то эта технология применима к любым базам на MS SQL 2005 и выше.
28. Алекс Ю (AlexO) 14.08.12 15:12
(27) pvase,
Извините, из статьи не видно что речь идет исключительно об 8-ке

это вы просто невнимательно читали :)
Большая часть, прочитав название темы, к которой мы сейчас пишем комменты "Приложение к публикации: "Давайте забудем о свертке БД?", сразу заинтересуется - а что это за исходная тема такая? Я че - буду читать какое-то "приложение" к непонятно чему, а на "исходную" статью даже и не взгляну?! И перейдет по ссылке Основная статья находится по адресу.
А там, в статье "Давайте забудем о свертке БД? Файловые группы и секции таблиц SQL, сжатие таблиц SQL", ниже заголовка написано, что "Алгоритм для 1С: Предприятие 8.0; 1С: Предприятие 8.1; 1С: Предприятие 8.2; Windows".
Т.е., четко и ясно :)
Никаких 7.7 и прочих "прямых доступов к SQL".
29. Dima Dima (bayce) 08.01.14 01:05
Мне кажется автор не затронул другую проблему.
А именно проблему работы "задним числом".
Во многих западных системах работать задним числом просто запрещено. Для этого у них есть документы корректировки. 1С бухгалтера любят в основном за это, за возможность работать задним числом. Но на базу в целом это влияет негативно. От сюда и вытекает основная идея свертки базы от айтишников. Если оставить только итоги,а прошлые документы убрать, то вероятность того, что бухгалтерия опять, что то поменяет задним числом, приближается к 0.


Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа