По теме из базы знаний
- МиниКейс "Закрытие месяца в УПП без остановки работы системы (Партионный учёт)"
- Рабочее место программиста на Linux. Серия лабораторных работ. Работа 1
- Подборка полезных советов по работе с программой 1С:Бухгалтерия 3.0
- Скальпель, зажим, … пластырь, валерьянка. Мы закончили..: инструменты работы бизнес-аналитика
- Как искусственный интеллект помогает в работе с требованиями
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Владимир ... хм ...
меня интересует "система" а не "код" - об ней и спрашиваю ...
интересна не столько конфигурация сколько еЁ схема: количество объектов, название, строение, подчинЁнность, общее более-менее подробное описание ...
код не интересует - это дело каждого ...
недостатки есть везде ... совершенство это идея, исполнение путь к нему ...
... ВОТподлецВОТ
меня интересует "система" а не "код" - об ней и спрашиваю ...
интересна не столько конфигурация сколько еЁ схема: количество объектов, название, строение, подчинЁнность, общее более-менее подробное описание ...
код не интересует - это дело каждого ...
недостатки есть везде ... совершенство это идея, исполнение путь к нему ...
... ВОТподлецВОТ
(+199) по (194)
Специально для Моха (для информации):
Я сделал "отчет", который "в лоб" просматривает все движения (2001 - 2009 годы) по всем товарам (60000 наименований) и "партиям". Просмотр делается циклом по справочнику номенклатуры и для каждого элемента справочника (или подчиненного ему "партионного" элемента) просматривается движение данного товара. При получении строки движения я имею: Кто, Кому, Что, МестоХранения, Сколько, Сумму, Валюту, Курс... совершённой операции с товаром. В движении по записям таблицы отображается: приход, продажа, возврат поставщику, возврат от покупателя, оплата поставщику, оплата от клиента, внутренние перемещения, списание, ... Т.е. "насчитать", имея такую информацию можно всё что угодно...
Первый просмотр - 5 минут.
Второй просмотр - 2 минуты.
Этот "отчет" выполнялся в сети.
Сервер БД - Advantage 9.x.
(200)
Я думаю - как это сделать...
Пока не придумал :-(
Уж больно простая схема базы данных. ;-)
Специально для Моха (для информации):
Я сделал "отчет", который "в лоб" просматривает все движения (2001 - 2009 годы) по всем товарам (60000 наименований) и "партиям". Просмотр делается циклом по справочнику номенклатуры и для каждого элемента справочника (или подчиненного ему "партионного" элемента) просматривается движение данного товара. При получении строки движения я имею: Кто, Кому, Что, МестоХранения, Сколько, Сумму, Валюту, Курс... совершённой операции с товаром. В движении по записям таблицы отображается: приход, продажа, возврат поставщику, возврат от покупателя, оплата поставщику, оплата от клиента, внутренние перемещения, списание, ... Т.е. "насчитать", имея такую информацию можно всё что угодно...
Первый просмотр - 5 минут.
Второй просмотр - 2 минуты.
Этот "отчет" выполнялся в сети.
Сервер БД - Advantage 9.x.
(200)
Я думаю - как это сделать...
Пока не придумал :-(
Уж больно простая схема базы данных. ;-)
Владимир:
в (146) ... пишешь что база составляет 9 Гигов ... это база за сколько лет ... ? она у вас в дбф ...?
(200) ... простота ... это и хорошо ! ...
поэтому, чего тут думать-то: "рисуешь" подробную схему, "пишешь" подробное описание ... МЫ тебя критикуем - ТЫ на нас обижаешься - ВСёёёЁ ...
... дАвАй уже "подлец" не томи ... обогатим друг-друга разочарованиями ...
... вот ...
в (146) ... пишешь что база составляет 9 Гигов ... это база за сколько лет ... ? она у вас в дбф ...?
(200) ... простота ... это и хорошо ! ...
поэтому, чего тут думать-то: "рисуешь" подробную схему, "пишешь" подробное описание ... МЫ тебя критикуем - ТЫ на нас обижаешься - ВСёёёЁ ...
... дАвАй уже "подлец" не томи ... обогатим друг-друга разочарованиями ...
... вот ...
(202)
1) База 9 гигабайт за 9 лет. Считая объем только DBF файлов. База DBF-ная по сути, и клиент-серверная (не на всех участках) по способу работы с ней.
2) Вот я и думаю, как описать схему базы данных. С одной стороны - просто, а с другой - сложно. Дабы критикующему я мог сказать (и главное, успокоить себя) - "ты ничего не понял". И не сильно обидеться на критикующего. ;-)
Схема, действительно, очень простая. Всё движение в одной таблице БД. Каждая строка документа кладется в строку (или две строки) таблицы движения (ТД). Документы без строк - одна строка шапочной информации. Большинство документов "строка в строку". Для строки документа перемещения - две строки. С минусом склада отправителя и плюсом склада получателя. Для строки розничных документов - две строки. Одна описывает количество, а вторая деньги. Т.е. отгрузка и оплата - разом.
Суть формат строки ТД я уже выше приводил. Остальное - детали.
Наименование - дата операции (движения)+RecNoДокумента
ТипЗаписи - количество, деньги, ОИ по товарам, ОИ по деньгам.
ТипУчета
ТипМетода - автоматическая (делается документом), ручная (разноска оплаты)
ЗнакЗаписи - значение: "+ -" знак ОИ, нулевые итоги не хранятся.
Документ - документ "породивший" запись в автоматическом режиме.
Источник - документ "гасящий" данную строку возвратом или деньгами.
Клиент
Фирма
Склад
Товар
Партия
Количество
Сумма
Валюта
Курс
Key - уникальный ключ для ОИ
Otb0 - различные "сложные ключи" для ускорения просмотра ТД
...
Otb7
Для разных "ТипЗаписи" имеют смысл (заносятся и считываются) различные поля ТД.
При использовании "DBEng32 для CodeBase 6.5" полей Key и Otb в записи ТД не существовало, т.к. в этой разработке можно добавлять индексы к штатным таблицам 1Са. Для родных DBF и Advantage - это реальные поля в записи ТД. И уже по ним строится индекс в индексном файле. Полей Otb - реально 8 штук.
Вся остальная информация для отчетов тащится из документа по полю "Документ". Сложность в части скорости работы отчета, это тащить информацию из строк документа. Для родных DBF-ов, CodeBase 6.5, Advantage - разная методика.
Вопрос - не просматривать всё движение (если это требуется отчету) решается тремя способами, в зависимости от характера отчета (даю очень общее описание):
1) Значением ключей ТД с применением или без применения дополнительных возможностей CodeBase или Advantage.
2) Просмотром ТД с конца движения (с применением пункта #1) с учетом значения ОИ.
3) Отчет "по алгоритму" просматривает всегда (с применением пункта #1) всю ТД с начала. Но в процессе формирования отчета он записывает подобие контрольных точек промежуточных вычислений ("итогов"). Эти точки по содержанию "понятны" только этому отчету. Примерный формат записи "контрольной" точки:
ТипТочки
ДатаОперацииИзТД
ОписаниеТочки
ЗначенияТочки
Повторное выполнение отчета использует "контрольные точки", созданные предыдущим отчетом и не выполняет просмотр движения с самого начала. За актуальностью контрольных точек "следит" функция выполняемая при изменении документа, влияющего на ТД. Производится "пометка" признаком на основании даты документа (движения) не актуальных "контрольных точек". Частота (интервал по дате) контрольных точек произвольный и зависит от характера отчета. Отсутствие "подходящей" (полезной) "контрольной точки" лишь увеличивает время выполнения текущего запуска отчета. Методика находится на стадии тестирования. Т.к. см. времена из сообщения (201) данной темы...
Думаю, описание схемы базы данных для заказ-нарядов (виды работ, тарифы и т.д), штрих-кодов, дисконтных карт, проходной, автостоянки, графика работы сотрудников, фотографий сотрудников и товаров и т.д не интересны в контексте данной темы форума.
P.S. По взятию информации из строк документов.
Я поискал в конфигурации "потребность" в этом действии. Не нашёл. Вроде обходимся, на данный момент, без этого...
1) База 9 гигабайт за 9 лет. Считая объем только DBF файлов. База DBF-ная по сути, и клиент-серверная (не на всех участках) по способу работы с ней.
2) Вот я и думаю, как описать схему базы данных. С одной стороны - просто, а с другой - сложно. Дабы критикующему я мог сказать (и главное, успокоить себя) - "ты ничего не понял". И не сильно обидеться на критикующего. ;-)
Схема, действительно, очень простая. Всё движение в одной таблице БД. Каждая строка документа кладется в строку (или две строки) таблицы движения (ТД). Документы без строк - одна строка шапочной информации. Большинство документов "строка в строку". Для строки документа перемещения - две строки. С минусом склада отправителя и плюсом склада получателя. Для строки розничных документов - две строки. Одна описывает количество, а вторая деньги. Т.е. отгрузка и оплата - разом.
Суть формат строки ТД я уже выше приводил. Остальное - детали.
Наименование - дата операции (движения)+RecNoДокумента
ТипЗаписи - количество, деньги, ОИ по товарам, ОИ по деньгам.
ТипУчета
ТипМетода - автоматическая (делается документом), ручная (разноска оплаты)
ЗнакЗаписи - значение: "+ -" знак ОИ, нулевые итоги не хранятся.
Документ - документ "породивший" запись в автоматическом режиме.
Источник - документ "гасящий" данную строку возвратом или деньгами.
Клиент
Фирма
Склад
Товар
Партия
Количество
Сумма
Валюта
Курс
Key - уникальный ключ для ОИ
Otb0 - различные "сложные ключи" для ускорения просмотра ТД
...
Otb7
Для разных "ТипЗаписи" имеют смысл (заносятся и считываются) различные поля ТД.
При использовании "DBEng32 для CodeBase 6.5" полей Key и Otb в записи ТД не существовало, т.к. в этой разработке можно добавлять индексы к штатным таблицам 1Са. Для родных DBF и Advantage - это реальные поля в записи ТД. И уже по ним строится индекс в индексном файле. Полей Otb - реально 8 штук.
Вся остальная информация для отчетов тащится из документа по полю "Документ". Сложность в части скорости работы отчета, это тащить информацию из строк документа. Для родных DBF-ов, CodeBase 6.5, Advantage - разная методика.
Вопрос - не просматривать всё движение (если это требуется отчету) решается тремя способами, в зависимости от характера отчета (даю очень общее описание):
1) Значением ключей ТД с применением или без применения дополнительных возможностей CodeBase или Advantage.
2) Просмотром ТД с конца движения (с применением пункта #1) с учетом значения ОИ.
3) Отчет "по алгоритму" просматривает всегда (с применением пункта #1) всю ТД с начала. Но в процессе формирования отчета он записывает подобие контрольных точек промежуточных вычислений ("итогов"). Эти точки по содержанию "понятны" только этому отчету. Примерный формат записи "контрольной" точки:
ТипТочки
ДатаОперацииИзТД
ОписаниеТочки
ЗначенияТочки
Повторное выполнение отчета использует "контрольные точки", созданные предыдущим отчетом и не выполняет просмотр движения с самого начала. За актуальностью контрольных точек "следит" функция выполняемая при изменении документа, влияющего на ТД. Производится "пометка" признаком на основании даты документа (движения) не актуальных "контрольных точек". Частота (интервал по дате) контрольных точек произвольный и зависит от характера отчета. Отсутствие "подходящей" (полезной) "контрольной точки" лишь увеличивает время выполнения текущего запуска отчета. Методика находится на стадии тестирования. Т.к. см. времена из сообщения (201) данной темы...
Думаю, описание схемы базы данных для заказ-нарядов (виды работ, тарифы и т.д), штрих-кодов, дисконтных карт, проходной, автостоянки, графика работы сотрудников, фотографий сотрудников и товаров и т.д не интересны в контексте данной темы форума.
P.S. По взятию информации из строк документов.
Я поискал в конфигурации "потребность" в этом действии. Не нашёл. Вроде обходимся, на данный момент, без этого...
(205) ... ну почему же не используют ... очень даже используют ...
... сейчас мода на разделение (большие программы - большие коллективы - много справочников - меньше нагрузка, быстрее освобождаются таблицы и т.д. и т.п. и др. и пр.) - вот 1С и модничает (впрочем для неё это очень даже выгодно) ...
... вот ...
... сейчас мода на разделение (большие программы - большие коллективы - много справочников - меньше нагрузка, быстрее освобождаются таблицы и т.д. и т.п. и др. и пр.) - вот 1С и модничает (впрочем для неё это очень даже выгодно) ...
... вот ...
... ммм ... неужели я ошибаюсь ... ВСЕ ...
... но с ростом версий разделение углубляется ...
... раньше данные хранились в "одном" месте - теперь "в разных" ...
... упрощают хранение данных - усложняют сборку ...
... вот ...
... но с ростом версий разделение углубляется ...
... раньше данные хранились в "одном" месте - теперь "в разных" ...
... упрощают хранение данных - усложняют сборку ...
... вот ...
Владимир ... "ПОДЛЕЦ" ... хватит кормить нАс нЬюнсами ... !!! ... ??? ...
... дАЁшь ... стАтью ... описАние ... конфигурАцию ...
... чАстных вопросов много ... а твои - "масса ньЮансов" уже это... того... блин ... рАздражАют ...
... дАвАй уже ... дАвАй ...
... вОООт ...
п.с. и как же ТЫ опрашиваешь данные ...хм ... кольни нЬансик ... жУть кАк интересно ...
... дАЁшь ... стАтью ... описАние ... конфигурАцию ...
... чАстных вопросов много ... а твои - "масса ньЮансов" уже это... того... блин ... рАздражАют ...
... дАвАй уже ... дАвАй ...
... вОООт ...
п.с. и как же ТЫ опрашиваешь данные ...хм ... кольни нЬансик ... жУть кАк интересно ...
(211) Запрос сам не попадает в индекс. Запрос ПИШУТ с условием по полям индекса, причем на равенство полей конкретным значениям. Стоит только выбрать условия В, >, < и т.п. получаем как минимум не быстрый поиск по индексу, а сканирование индекса.
(212) Никаких блокировок? Вы получаете не данные, а гэ. Блокировки для получения достоверных данных в отчете ставятся ДО чтения.
(213) Выборка по циклу - это выборка по Table Scan.
В общем, имеем схему работы с грязным чтением.
(214) Что означает "Клиент-сервер "?
(212) Никаких блокировок? Вы получаете не данные, а гэ. Блокировки для получения достоверных данных в отчете ставятся ДО чтения.
(213) Выборка по циклу - это выборка по Table Scan.
В общем, имеем схему работы с грязным чтением.
(214) Что означает "Клиент-сервер "?
(218)(Моха)
по (212)
Никаких блокировок - это в контексте Вашей фразы "блокируем почти все строки таблицы". Естественно, получая движение по конкретному товару, клиенту, фирме и т.д. имеет смысл чего-либо блокировать. Я и блокирую. Но не в сильный ущерб для других пользователей. Еще есть "технологические" блокировки при "движении" по индексному файлу (не длительные). Но это уже делает сервер БД.
по (214)
Клиент-сервер это термин, обозначающий принцип взаимодействия "проблемного" (клиента) приложения с базой данных. С какого-то момента ставят равенство между этим понятием и SQL сервером. Я не ставлю. Можно немного об этом узнать, скачав мою разработку "DBEng32 для CodeBase/Advantage". Там в корне есть файл *.DOC.
(217)
Александр.
А не забивайте себе голову моими бреднями. Легче жить будет...
P.S. Я опубликовал еще одну заметку по теме "запросы". Доведут до "-5", уйду с сайта. Пойду воспитывать внуков...
по (212)
Никаких блокировок - это в контексте Вашей фразы "блокируем почти все строки таблицы". Естественно, получая движение по конкретному товару, клиенту, фирме и т.д. имеет смысл чего-либо блокировать. Я и блокирую. Но не в сильный ущерб для других пользователей. Еще есть "технологические" блокировки при "движении" по индексному файлу (не длительные). Но это уже делает сервер БД.
по (214)
Клиент-сервер это термин, обозначающий принцип взаимодействия "проблемного" (клиента) приложения с базой данных. С какого-то момента ставят равенство между этим понятием и SQL сервером. Я не ставлю. Можно немного об этом узнать, скачав мою разработку "DBEng32 для CodeBase/Advantage". Там в корне есть файл *.DOC.
(217)
Александр.
А не забивайте себе голову моими бреднями. Легче жить будет...
P.S. Я опубликовал еще одну заметку по теме "запросы". Доведут до "-5", уйду с сайта. Пойду воспитывать внуков...
опубликовал еще одну заметку по теме "запросы". Доведут до "-5", уйду с сайта. Пойду воспитывать внуков...
- внуки - это хорошо! ;-)интересно - в чем их воспитает обиженный дедушка: в ненависти к 1С, Инфостарту и Мохе????!!!! ;-)
(220)
(221) :))))))).
Владимир пишет:
Естественно, получая движение по конкретному товару, клиенту, фирме и т.д. имеет смысл чего-либо блокировать. Я и блокирую. Но не в сильный ущерб для других пользователей.
Когда Вы делаете отчет по клиентамАМ или товарАМ Вы делаете отчет по каждому клиенту или товару отдельно, а потом их ручками собираете? Если все-таки как минимум короткие запросы по нескольким клиентам или товарам, то только шайтан-машина может обойтись без чувствительных блокировок в Вашем случае. ИМХО.
Естественно, получая движение по конкретному товару, клиенту, фирме и т.д. имеет смысл чего-либо блокировать. Я и блокирую. Но не в сильный ущерб для других пользователей.
(221) :))))))).
(224)(Моха)
"Когда Вы делаете отчет по клиентамАМ или товарАМ Вы делаете отчет по каждому клиенту или товару отдельно, а потом их ручками собираете?"
- Да.
"Если все-таки как минимум короткие запросы по нескольким клиентам или товарам,"
- См. (223) на (222).
"то только шайтан-машина может обойтись без чувствительных блокировок в Вашем случае."
- Собираем данные, например, по товару - блокируем элемент справочника Номенклатура.
"Когда Вы делаете отчет по клиентамАМ или товарАМ Вы делаете отчет по каждому клиенту или товару отдельно, а потом их ручками собираете?"
- Да.
"Если все-таки как минимум короткие запросы по нескольким клиентам или товарам,"
- См. (223) на (222).
"то только шайтан-машина может обойтись без чувствительных блокировок в Вашем случае."
- Собираем данные, например, по товару - блокируем элемент справочника Номенклатура.
(220) ОК. За счет чего достигается не сильный ущерб при блокировках? Почему во всех других флагманских системах он сильный, а у Вас не сильный? Это есть в *.DOC? Или ссылка на это описание всего лишь отмаза для затяжки времени?
Прим. Где Вы видели, что я приравниваю запросы и SQL-запросы? Я специально не пишу SQL.
Прим. Где Вы видели, что я приравниваю запросы и SQL-запросы? Я специально не пишу SQL.
(228) Это нормально. Таблицу полностью ни одна система не блокирует. Я пока не вижу, чем таким отличается Ваша система от других, что позволяет ей быстро и беспроблемно работать без итогов. пока все как в анеке "Белые овцы мои. ... Черные тоже мои."
НЕ ВИДНА РАЗНИЦА кроме как отказ от итогов, который НЕ даст выигрыша в скорости.
НЕ ВИДНА РАЗНИЦА кроме как отказ от итогов, который НЕ даст выигрыша в скорости.
(229-230)(Моха)
"За счет чего достигается не сильный ущерб при блокировках?"
- Сложный вопрос. Думаю, прежде всего из-за простоты схемы БД и меньшей длительности выполнения различных манипуляций с данными.
"Почему во всех других флагманских системах он сильный, а у Вас не сильный?"
- Я и не говорил, что он "сильный" или "не сильный". Вы спросили "как", я ответил.
"Это есть в *.DOC? Или ссылка на это описание всего лишь отмаза для затяжки времени?"
- Я в DOC-у Вас "отправлял" по поводу вопроса "Что означает "Клиент-сервер "?" в НАШЕЙ реализации этого понятия.
"Где Вы видели, что я приравниваю запросы и SQL-запросы?"
- Нигде. Я сказал, что часто люди ставят равенство между этим понятием (клиент-сервер) и SQL сервером. И что я с этим "равенством" не согласен.
"Я пока не вижу, чем таким отличается Ваша система от других, что позволяет ей быстро и беспроблемно работать без итогов."
- Думаю, ей " беспроблемно" позволяет работать отсутствие её присутствия для конечного пользователя. И направленности на нужды торговли, а не бух.учета. Что касается быстроты, то чудес не бывает. Документы меньше обновляют данных - быстрее проводятся. Итогов меньше ведется - отчеты дольше работают. Далее смотрим, что важней. У нас важней скорость проведения документов.
"НЕ ВИДНА РАЗНИЦА кроме как отказ от итогов, который НЕ даст выигрыша в скорости."
- См. предыдущий абзац. И еще хочу напомнить, то с чего мы начали обсуждение. Итоги - это "помеха" для условий сформулированных в (88) сообщении данной темы. Но, думаю, благо для других "принципов" построения системы.
"За счет чего достигается не сильный ущерб при блокировках?"
- Сложный вопрос. Думаю, прежде всего из-за простоты схемы БД и меньшей длительности выполнения различных манипуляций с данными.
"Почему во всех других флагманских системах он сильный, а у Вас не сильный?"
- Я и не говорил, что он "сильный" или "не сильный". Вы спросили "как", я ответил.
"Это есть в *.DOC? Или ссылка на это описание всего лишь отмаза для затяжки времени?"
- Я в DOC-у Вас "отправлял" по поводу вопроса "Что означает "Клиент-сервер "?" в НАШЕЙ реализации этого понятия.
"Где Вы видели, что я приравниваю запросы и SQL-запросы?"
- Нигде. Я сказал, что часто люди ставят равенство между этим понятием (клиент-сервер) и SQL сервером. И что я с этим "равенством" не согласен.
"Я пока не вижу, чем таким отличается Ваша система от других, что позволяет ей быстро и беспроблемно работать без итогов."
- Думаю, ей " беспроблемно" позволяет работать отсутствие её присутствия для конечного пользователя. И направленности на нужды торговли, а не бух.учета. Что касается быстроты, то чудес не бывает. Документы меньше обновляют данных - быстрее проводятся. Итогов меньше ведется - отчеты дольше работают. Далее смотрим, что важней. У нас важней скорость проведения документов.
"НЕ ВИДНА РАЗНИЦА кроме как отказ от итогов, который НЕ даст выигрыша в скорости."
- См. предыдущий абзац. И еще хочу напомнить, то с чего мы начали обсуждение. Итоги - это "помеха" для условий сформулированных в (88) сообщении данной темы. Но, думаю, благо для других "принципов" построения системы.
(231)
Вопрос дополнительных индексов имеют косвенное отношение к моим описаниям системы. Индексы есть - отчеты работают быстрее, а нет - медленнее. А для обновления БД хватает одного индекса. Там, выше по тексту, я написал, что Key - уникальный ключ для ОИ. Описался. Это уникальный ключ для всех видов записей. Но, выше, я написал, что для сервера CodeBase есть возможность иметь дополнительные индексы. С индексными выражениями как в FoxPro. Для Advantage я не сделал такой возможности. Пока обходимся динамическими фильтрами. Не хватит этой возможности - сделаю и в Advantage дополнительные индексы. Работы там на пару дней... ;-)
Вопрос дополнительных индексов имеют косвенное отношение к моим описаниям системы. Индексы есть - отчеты работают быстрее, а нет - медленнее. А для обновления БД хватает одного индекса. Там, выше по тексту, я написал, что Key - уникальный ключ для ОИ. Описался. Это уникальный ключ для всех видов записей. Но, выше, я написал, что для сервера CodeBase есть возможность иметь дополнительные индексы. С индексными выражениями как в FoxPro. Для Advantage я не сделал такой возможности. Пока обходимся динамическими фильтрами. Не хватит этой возможности - сделаю и в Advantage дополнительные индексы. Работы там на пару дней... ;-)
Можно я скажу, что такое "клиент-сервер", не читая вашего файла?
Клиент-сервер - технология, по которой некоторые "команды", генерируемые клиентом выполняются сервером. В применении к базам данных это как правило передача клиентом серверу команды, возможно с набором данных, на действие(я) с данными/метаданными базы и, возможно, на передачу сервером данных куда-либо (как правило клиенту).
По-моему это тривиально.
Что касается (88). В 8-ке давно такое реализовано. В УТ есть галка, которая дает выбор фиксации движений по партиям или на момент проведения документа, или с помощью штатной обработки, как правило, в конце месяца.
Вас не сильно смущает, что УЖЕ РЕАЛИЗОВАННЫЙ В ТИПОВОЙ механизм почему-то никто почти не хочет юзать, а ТОЧНО ТАКОЙ ЖЕ ВАШ нахваливают, называя чуть ли не панацеей?
Кто не хочет проводить оперативно по партиям? Сказать, где галка в УТ? Пользуйтесь! Это круто! Только потом расскажите, что заставило вас отказаться от отложенных движений. Уж больно интересно.
Простая схема БД, как известно, как раз является источником блокировок.
Я уже писал, что система, направленная на нужды торговли НЕ НУЖНА, точнее она не может быть фронтом. Т.к. вся движуха начинается с выписки бухгалтерских первичных документов.
Клиент-сервер - технология, по которой некоторые "команды", генерируемые клиентом выполняются сервером. В применении к базам данных это как правило передача клиентом серверу команды, возможно с набором данных, на действие(я) с данными/метаданными базы и, возможно, на передачу сервером данных куда-либо (как правило клиенту).
По-моему это тривиально.
Что касается (88). В 8-ке давно такое реализовано. В УТ есть галка, которая дает выбор фиксации движений по партиям или на момент проведения документа, или с помощью штатной обработки, как правило, в конце месяца.
Вас не сильно смущает, что УЖЕ РЕАЛИЗОВАННЫЙ В ТИПОВОЙ механизм почему-то никто почти не хочет юзать, а ТОЧНО ТАКОЙ ЖЕ ВАШ нахваливают, называя чуть ли не панацеей?
Кто не хочет проводить оперативно по партиям? Сказать, где галка в УТ? Пользуйтесь! Это круто! Только потом расскажите, что заставило вас отказаться от отложенных движений. Уж больно интересно.
Простая схема БД, как известно, как раз является источником блокировок.
Я уже писал, что система, направленная на нужды торговли НЕ НУЖНА, точнее она не может быть фронтом. Т.к. вся движуха начинается с выписки бухгалтерских первичных документов.
(273)(Моха)
Я не буду таскать "цитаты" из наших текстов. Мы с Вами всё помним из наших текстов.
1) Вы меня спросили, что означает "клиент-сервер". Я ответил. И дал Вам дополнительную информацию о своих разработках.
2) Разнесение фиксации движения по партиям от проведения документов это "плохой" алгоритм. Думаю, поэтому его и не используют. И меня это не смущает (не удивляет). Весь вопрос (поднятый мной в данной теме) - это, ЧТО делать в момент фиксации. Нам удается фиксировать ровно тот состав информации, которого достаточно для ТОРГОВЛИ. Для учета - отчетами.
3) Мне не известно случаи, когда упрощение схемы базы данных усугубляет проблемы блокировки. Если эту тему обсуждать, то думаю, имеет смысл определиться с понятием "простая". Тема про блокировки очень интересная, но, давайте её обсудим в другой раз?
4) Еще раз повторяю, что у нас печатаются все первичные документы сразу после ввода документа в БД в нашей системе. Необходимые поставщику, клиенту, складскому работнику, ремонтнику и т.д. И содержание этих документов полностью отражает реальное состояние торговли. А те кто вводит эти документы не использую своих "записных книжечек"...
Я не буду таскать "цитаты" из наших текстов. Мы с Вами всё помним из наших текстов.
1) Вы меня спросили, что означает "клиент-сервер". Я ответил. И дал Вам дополнительную информацию о своих разработках.
2) Разнесение фиксации движения по партиям от проведения документов это "плохой" алгоритм. Думаю, поэтому его и не используют. И меня это не смущает (не удивляет). Весь вопрос (поднятый мной в данной теме) - это, ЧТО делать в момент фиксации. Нам удается фиксировать ровно тот состав информации, которого достаточно для ТОРГОВЛИ. Для учета - отчетами.
3) Мне не известно случаи, когда упрощение схемы базы данных усугубляет проблемы блокировки. Если эту тему обсуждать, то думаю, имеет смысл определиться с понятием "простая". Тема про блокировки очень интересная, но, давайте её обсудим в другой раз?
4) Еще раз повторяю, что у нас печатаются все первичные документы сразу после ввода документа в БД в нашей системе. Необходимые поставщику, клиенту, складскому работнику, ремонтнику и т.д. И содержание этих документов полностью отражает реальное состояние торговли. А те кто вводит эти документы не использую своих "записных книжечек"...
(238)
3) Мне не известно случаи, когда упрощение схемы базы данных усугубляет проблемы блокировки. Если эту тему обсуждать, то думаю, имеет смысл определиться с понятием "простая". Тема про блокировки очень интересная, но, давайте её обсудим в другой раз?
Этот случай является классикой жанра. Общий журнал документов в 7-ке.
Владимир пишет:
2) Разнесение фиксации движения по партиям от проведения документов это "плохой" алгоритм. Думаю, поэтому его и не используют. И меня это не смущает (не удивляет). Весь вопрос (поднятый мной в данной теме) - это, ЧТО делать в момент фиксации. Нам удается фиксировать ровно тот состав информации, которого достаточно для ТОРГОВЛИ. Для учета - отчетами.
От 1С отличие только в том, что копятся итоги. И никто, кстати, не заставляет строить отчеты на итогах. Можно на движениях. Только не строит никто почему-то.
2) Разнесение фиксации движения по партиям от проведения документов это "плохой" алгоритм. Думаю, поэтому его и не используют. И меня это не смущает (не удивляет). Весь вопрос (поднятый мной в данной теме) - это, ЧТО делать в момент фиксации. Нам удается фиксировать ровно тот состав информации, которого достаточно для ТОРГОВЛИ. Для учета - отчетами.
Владимир пишет:
4) Еще раз повторяю, что у нас печатаются все первичные документы сразу после ввода документа в БД в нашей системе. Необходимые поставщику, клиенту, складскому работнику, ремонтнику и т.д. И содержание этих документов полностью отражает реальное состояние торговли. А те кто вводит эти документы не использую своих "записных книжечек"...
Это противоречит Вашему заявлению, что система не направлена на нужды бухгалтерии. Она для бухии хотя бы первичку выдает.
4) Еще раз повторяю, что у нас печатаются все первичные документы сразу после ввода документа в БД в нашей системе. Необходимые поставщику, клиенту, складскому работнику, ремонтнику и т.д. И содержание этих документов полностью отражает реальное состояние торговли. А те кто вводит эти документы не использую своих "записных книжечек"...
Меня еще прикалывает то, что Владимир призывает нас не делать промежуточные движения, которые ускоряют контрольные действия при проведении следующих документов. Это типа взаиморасчеты и т.п. Прикольно.
Ну давайте не будем их делать :). Тогда при проведении следующего дока отчет по взаиморасчетам прийдется запустить :).
Пипец :). Как прям как в анеке :).
Ну давайте не будем их делать :). Тогда при проведении следующего дока отчет по взаиморасчетам прийдется запустить :).
Пипец :). Как прям как в анеке :).
"Моха".
Ну, давайте завяжем это разговор?
Я же не рассказывал Вам как у нас устроен журнал документов. У нас есть журнал документов. Общий для всех видов документов с массой навороченных отборов, фильтров, поисков и т.д. в котором "сидит" 99% наших пользователей. Но тема форума не о журналах документов, блокировках и пр.
Извините меня, пожалуйста...
Ну, давайте завяжем это разговор?
Я же не рассказывал Вам как у нас устроен журнал документов. У нас есть журнал документов. Общий для всех видов документов с массой навороченных отборов, фильтров, поисков и т.д. в котором "сидит" 99% наших пользователей. Но тема форума не о журналах документов, блокировках и пр.
Извините меня, пожалуйста...
Моха, не бузи!!!! все проблемы - в переходных периодах! когда затруднения с регламентом работы и прочее - получается сильный "разрыв" между фактом и учетом, когда начинается нормальный порядок - разрыв между учетом и фактом становится гораздо меньше - в итоге сходя на нет. у меня например на моем складском комплексе - основной тормоз процесса - это не до конца выстроенный регламент работы по "буии" -= у меня на него просто сил-времени пока нет.
.
И простая структура базы - совсем не обязательно источник блокировок. Те же ВМС посторены на максимальном упрощениии документов/операций - и что интересно не правда ли - такое понятие как заднее число - там действительно не нужно/вредно. Все эти потуги с задним числом - исключительно из-за бардака и прочих бяк...
.
А считать партионку - для процесса торговли - нужно очень редко. Для планирования самого процесса торговли - да. Для анализа итогов процесса торговли - тоже да. А для самого процесса торговли - ну очень редко. Та же фармация, с которой я трахался успешно 4 года - проблемы заднего числа не сущестоввало - просто потому что такая "система" - перепроводился и регулярно - но это перепроведение - больше для технических нужд.
.
вот и сейчас - у меня ГП стоит хрен знает где. Но это не мешает мне работать складу и выписывать отгрузочные доки. потому что партионка - нафиг мне сейчас не нужна...
.
И простая структура базы - совсем не обязательно источник блокировок. Те же ВМС посторены на максимальном упрощениии документов/операций - и что интересно не правда ли - такое понятие как заднее число - там действительно не нужно/вредно. Все эти потуги с задним числом - исключительно из-за бардака и прочих бяк...
.
А считать партионку - для процесса торговли - нужно очень редко. Для планирования самого процесса торговли - да. Для анализа итогов процесса торговли - тоже да. А для самого процесса торговли - ну очень редко. Та же фармация, с которой я трахался успешно 4 года - проблемы заднего числа не сущестоввало - просто потому что такая "система" - перепроводился и регулярно - но это перепроведение - больше для технических нужд.
.
вот и сейчас - у меня ГП стоит хрен знает где. Но это не мешает мне работать складу и выписывать отгрузочные доки. потому что партионка - нафиг мне сейчас не нужна...
> Тогда при проведении следующего дока отчет по взаиморасчетам прийдется запустить :). Пипец :). Как прям как в анеке :).
- а зачем? построить молжно по разному систему. беда в том, что не у всех нас хватает сил и смелости отойти ДАЛЕКО от типовых решений. Вот и все.
у меня например, стоит на 70% готовая ВМС - я ее не использую - в первую очередь потому что это требует четкого выполнения определенными людьми определенных действий - а я на это пока не могу рассчитывать с 98% уверенностью... вот и решаютсяч проблемы "раком через гланды"...
- а зачем? построить молжно по разному систему. беда в том, что не у всех нас хватает сил и смелости отойти ДАЛЕКО от типовых решений. Вот и все.
у меня например, стоит на 70% готовая ВМС - я ее не использую - в первую очередь потому что это требует четкого выполнения определенными людьми определенных действий - а я на это пока не могу рассчитывать с 98% уверенностью... вот и решаютсяч проблемы "раком через гланды"...
(252)
Нет. :-)
У меня "компьютер" занимает половину квартиры. Внукам негде бегать.
А Вы думали, что мне удалось упростить наши задачи автоматизации до уровня палочек и узелков? ;-)
Хотя, я помню, кода начинал программировать, рассказал (с гордостью) отцу о новом алгоритме поиска для ИПС-ов (из диссертации моего учителя-шефа). Отец выслушал. Попросил распечатки исходных данных нашего замера производительности. И с помощью карандаша, очков, чертежной линейки и указательного пальца выдал результат поиска в несколько раз быстрей чем на ЭВМ-е.
...вот...(с)
Нет. :-)
У меня "компьютер" занимает половину квартиры. Внукам негде бегать.
А Вы думали, что мне удалось упростить наши задачи автоматизации до уровня палочек и узелков? ;-)
Хотя, я помню, кода начинал программировать, рассказал (с гордостью) отцу о новом алгоритме поиска для ИПС-ов (из диссертации моего учителя-шефа). Отец выслушал. Попросил распечатки исходных данных нашего замера производительности. И с помощью карандаша, очков, чертежной линейки и указательного пальца выдал результат поиска в несколько раз быстрей чем на ЭВМ-е.
...вот...(с)
... ОНИ смотрели в "содержание" и результат который ОНИ получали был осмысленным, зачем, для чего, как ... +образование ...
... сейчас "форма" поразила наше вОООбражение ... -образование ...
... вОООбщем как всЕгДА ... конфликт отцов и детей в форме "ДО основания а затем" ...
... вотТАКОЙстарческийМЕТАболизм ...
... сейчас "форма" поразила наше вОООбражение ... -образование ...
... вОООбщем как всЕгДА ... конфликт отцов и детей в форме "ДО основания а затем" ...
... вотТАКОЙстарческийМЕТАболизм ...
(245) Да делайте свой пластилиновый вертолет. К тому же вспомнилось, что ставить блокировки надо ДО чтения данных и ПО последнюю запись транзакции. Прочитать данные о номенклатуре и отпустить эту запись = грязное чтение. Это не раз на семинаре софтпоинта, кстати, упоминали.
Ты не заметил, что у него в таблице "партия" есть?
Мне не очень еще понятно, как это товарищ опеределяет партию при расходе, это он все движения таблицы своей суммирует?
(246) Как? Конкретный пример можно?
Прим. Не разделяю гоп-оптимизма. К тому же еще раз повторюсь: указанные Владимиром способы учета влегкую реализуются на УТ, но проблемы не снимают. Это почему-то никто не берет в расчет.
Ты не заметил, что у него в таблице "партия" есть?
Мне не очень еще понятно, как это товарищ опеределяет партию при расходе, это он все движения таблицы своей суммирует?
(246) Как? Конкретный пример можно?
Прим. Не разделяю гоп-оптимизма. К тому же еще раз повторюсь: указанные Владимиром способы учета влегкую реализуются на УТ, но проблемы не снимают. Это почему-то никто не берет в расчет.
(259)
Вроде не мне адресовано сообщение.
Сергей. Во - как я Вас подставил...
Вашу тему "заболтал".
Еще и отвечать за меня приходится.
А, откройте новую тему...
(Моха)
На семинаре Вам говорили всё правильно.
Я уже Вам говорил (писал) в этой теме, что у Вас отличная система.
Если Вы хотите мне сообщить о "плохости" моей "системы", то Вы мне об этом сообщили.
Я полностью с Вами согласен. Во всём!!!
Чего еще Вам надо от данной темы?
Вроде не мне адресовано сообщение.
Сергей. Во - как я Вас подставил...
Вашу тему "заболтал".
Еще и отвечать за меня приходится.
А, откройте новую тему...
(Моха)
На семинаре Вам говорили всё правильно.
Я уже Вам говорил (писал) в этой теме, что у Вас отличная система.
Если Вы хотите мне сообщить о "плохости" моей "системы", то Вы мне об этом сообщили.
Я полностью с Вами согласен. Во всём!!!
Чего еще Вам надо от данной темы?
Владимир (hogik) пишет:
Я полностью с Вами согласен. Во всём!!!
Чего еще Вам надо от данной темы?
Хотелось бы вернуться к СУТИ темы. И перевести ее из русла "Как я думаю, что классно и првильно работаю без последовательности" в русло "Как и возможно ли вообще работать без последовательности правильно".
Я полностью с Вами согласен. Во всём!!!
Чего еще Вам надо от данной темы?
Обсуждение вашей системы неконструктивно, т.к. в ней явные методологические дыры. Почему ей пользуются, вопрос другой.
Кстати, вроде бы ответ уже раз 10 в ветке прозвучал.
Если не паримся о ГТД, то тупо контролируем остатки в текущем времени и делаем спец.обработку для анализа возможности изменений задним числом.
Если паримся о ГТД хотя бы по количеству, то дополнительно списываем и контролируем их.
Опять же последовательностей нет в обоих случаях. Усё.
Если не паримся о ГТД, то тупо контролируем остатки в текущем времени и делаем спец.обработку для анализа возможности изменений задним числом.
Если паримся о ГТД хотя бы по количеству, то дополнительно списываем и контролируем их.
Опять же последовательностей нет в обоих случаях. Усё.
(265) неправильно ты все понял.
- "регистр" бухитогов актуален всегда: тупо перепроведи доки за месяц (если проведутся ;-) и дай оборотку буху - он тебя распнет - потому что у многих она "сьедет" - вот тебе цена "актуальности"
- проблема не в регистрах, проблема в задействованном механизме временных итогов и отсутсвие в типовых механизмах алгоритмов, обеспечивающий актуальность данных без использования механизма временных итогов.
- проблема также в механизмах, например, журналов - с какого бодуна при длительном проведении например, я не могу записать новый документ? а потому что общий журнал все в ступоре держит!
- "регистр" бухитогов актуален всегда: тупо перепроведи доки за месяц (если проведутся ;-) и дай оборотку буху - он тебя распнет - потому что у многих она "сьедет" - вот тебе цена "актуальности"
- проблема не в регистрах, проблема в задействованном механизме временных итогов и отсутсвие в типовых механизмах алгоритмов, обеспечивающий актуальность данных без использования механизма временных итогов.
- проблема также в механизмах, например, журналов - с какого бодуна при длительном проведении например, я не могу записать новый документ? а потому что общий журнал все в ступоре держит!
Che Burashka Сергей пишет:
- проблема не в регистрах, проблема в задействованном механизме временных итогов и отсутсвие в типовых механизмах алгоритмов, обеспечивающий актуальность данных без использования механизма временных итогов.
Как предлагаешь это сделать? На справочниках? Или считать итоги налету? - проблема не в регистрах, проблема в задействованном механизме временных итогов и отсутсвие в типовых механизмах алгоритмов, обеспечивающий актуальность данных без использования механизма временных итогов.
Che Burashka Сергей пишет:
- проблема также в механизмах, например, журналов - с какого бодуна при длительном проведении например, я не могу записать новый документ? а потому что общий журнал все в ступоре держит!
Именно поэтому в 8-ке сделали каждому виду документа свою таблицу ;).
- проблема также в механизмах, например, журналов - с какого бодуна при длительном проведении например, я не могу записать новый документ? а потому что общий журнал все в ступоре держит!
(267)
- справочники имеет смысл юзать тогда, когда другое не подходит. тут вполне (по текущей реализации) подходят регистры. Итоги, можно сказать, считаются "налету", но за счет алгоритмического решения такой расчет абсолютно ненагрузочный, т.е. сравним с порядком времени, затрачиваемым на расчет итогов на ТА, в большинстве случаев - такой расчет вообще будет отсутсвовать... ну, по крайнйе мере надеюсь, так реализовать - кодирование потихоньку движется.. посмотрим что выйдет...
.
а в общий журнал как доки попадают? тупо запросом тянутся и формируется общий журнал?
Как предлагаешь это сделать? На справочниках? Или считать итоги налету?
- справочники имеет смысл юзать тогда, когда другое не подходит. тут вполне (по текущей реализации) подходят регистры. Итоги, можно сказать, считаются "налету", но за счет алгоритмического решения такой расчет абсолютно ненагрузочный, т.е. сравним с порядком времени, затрачиваемым на расчет итогов на ТА, в большинстве случаев - такой расчет вообще будет отсутсвовать... ну, по крайнйе мере надеюсь, так реализовать - кодирование потихоньку движется.. посмотрим что выйдет...
.
а в общий журнал как доки попадают? тупо запросом тянутся и формируется общий журнал?
(266)
Съедет оборотка как раз у тех, у кого и последовательность не восстановится, т.е. в условиях автоматизированного бардака.
Я же говорю о том, что идея Владимира четко укладывается на компоненту Бухучет и, напротив, совершено не стыкуется с регистрами.
тупо перепроведи доки за месяц (если проведутся) и дай оборотку буху - он тебя распнет - потому что у многих она "сьедет" - вот тебе цена "актуальности"
Съедет оборотка как раз у тех, у кого и последовательность не восстановится, т.е. в условиях автоматизированного бардака.
Я же говорю о том, что идея Владимира четко укладывается на компоненту Бухучет и, напротив, совершено не стыкуется с регистрами.
(270) Не только сталкивался, но и боролся. Успешно :D
Накосячить в любой системе можно. По сабжу - "без последовательностей, без временных итогов" - сразу 1с-ский регистровый механизм в топку. И компоненту Расчет - туда же. Последнее-то сомнений не вызывает? ;)
Накосячить в любой системе можно. По сабжу - "без последовательностей, без временных итогов" - сразу 1с-ский регистровый механизм в топку. И компоненту Расчет - туда же. Последнее-то сомнений не вызывает? ;)
Накосячить в любой системе можно.
- вот это ключевой момент. надо-то всего в момент "действия" сразу сказать - косяк или не косяк... и тут, например, при учете остатков ТМЦ (гтд) можно совершенно спокойно обойтись и без ГП и без временных итогов.
(266)
"в механизмах, например, журналов ... при длительном проведении например, я не могу записать новый документ?"
Сергей.
Журнал тут не виноват. ;-)
В 1С 7.7 при выполнении транзакции выполняется блокировка "первой попавшейся" таблицы на "пути" (алгоритме) действий внутри транзакции. Для документов - это журнал. И новый документ не может быть записан в базу не из-за журнала документов, а из-за необходимости чего-либо блокировать для обеспечение не противоречивой информации. Это делается так из-за того, что системе не известно - ЧТО будет менять и читать новый документ в момент своего проведения. Это самый простое решение. Снимается (решается) эта проблема "гибкими блокировками". Или уменьшением времени проведения документа.
"Моха", извините меня, пожалуйста. Опять о себе скажу... ;-) У нас блокируется некая запись в специальной фиктивной таблице. И в момент проведения документов "встаёт" всё. Даже запись элемента справочников. До разработки гибких блокировок я так и не добрался, т.к. у нас документы проводятся быстро...
Такую схему блокировки мы сделали, т.к. если в модуле проведения документа выполнить чтение элемента справочника, то у другого пользователя возникают проблемы с обновлением элемента справочника. И с точки зрения механизма транзакций - это нормально. Но механизма синхронизации транзакций по журналу документов не достаточно для обеспечения адекватного поведения системы в многопользовательском режиме.
"в механизмах, например, журналов ... при длительном проведении например, я не могу записать новый документ?"
Сергей.
Журнал тут не виноват. ;-)
В 1С 7.7 при выполнении транзакции выполняется блокировка "первой попавшейся" таблицы на "пути" (алгоритме) действий внутри транзакции. Для документов - это журнал. И новый документ не может быть записан в базу не из-за журнала документов, а из-за необходимости чего-либо блокировать для обеспечение не противоречивой информации. Это делается так из-за того, что системе не известно - ЧТО будет менять и читать новый документ в момент своего проведения. Это самый простое решение. Снимается (решается) эта проблема "гибкими блокировками". Или уменьшением времени проведения документа.
"Моха", извините меня, пожалуйста. Опять о себе скажу... ;-) У нас блокируется некая запись в специальной фиктивной таблице. И в момент проведения документов "встаёт" всё. Даже запись элемента справочников. До разработки гибких блокировок я так и не добрался, т.к. у нас документы проводятся быстро...
Такую схему блокировки мы сделали, т.к. если в модуле проведения документа выполнить чтение элемента справочника, то у другого пользователя возникают проблемы с обновлением элемента справочника. И с точки зрения механизма транзакций - это нормально. Но механизма синхронизации транзакций по журналу документов не достаточно для обеспечения адекватного поведения системы в многопользовательском режиме.
(275)
Думаю, в САПе нет журнала не потому что он не нужен, а потому что они не могут его сделать. Т.к. хотят "тупо запросом тянуть ". А он не тянется - большой очень. ;-) Но это другая тема. За неё я уже получил свои "-5"...
P.S. :-((( А как пишется "потому что" в данном случае?
Думаю, в САПе нет журнала не потому что он не нужен, а потому что они не могут его сделать. Т.к. хотят "тупо запросом тянуть ". А он не тянется - большой очень. ;-) Но это другая тема. За неё я уже получил свои "-5"...
P.S. :-((( А как пишется "потому что" в данном случае?
Владимир (hogik) пишет:
Думаю, в САПе нет журнала не потому что он не нужен, а потому что они не могут его сделать.
Вспомнилось ералашное "А почему тогда татары плохо живут?" :))))))))))
Думаю, в САПе нет журнала не потому что он не нужен, а потому что они не могут его сделать.
Почему в 8-ке не сделали, тоже не смогли?
Владимир (hogik) пишет:
В 1С 7.7 при выполнении транзакции выполняется блокировка "первой попавшейся" таблицы на "пути" (алгоритме) действий внутри транзакции.
А потом второй, третьей, четвертой ... В 8-ке блокируются отдельные записи, если скуль иного сам не сделает.В 1С 7.7 при выполнении транзакции выполняется блокировка "первой попавшейся" таблицы на "пути" (алгоритме) действий внутри транзакции.
Владимир (hogik) пишет:
Но механизма синхронизации транзакций по журналу документов не достаточно для обеспечения адекватного поведения системы в многопользовательском режиме.
Можно расшифровать фразу?
Но механизма синхронизации транзакций по журналу документов не достаточно для обеспечения адекватного поведения системы в многопользовательском режиме.
(278) (Моха)
"Можно расшифровать фразу?"
Думаю, перед тем как писать "А потом второй, третьей, четвертой..." надо было именно об этом спросить. ;-)
"Почему в 8-ке не сделали, тоже не смогли?"
Если не сделали (я об этом не знаю) то либо не смогли, либо не захотели. Т.к. при наличии "трех уровней" можно было бы "изогнуться" и сделать журналы. А чего еще делать "среднему" уровню? ;-) Про 1С 8.х на сайте изготовителя написано:
"... при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере...".
P.S. О!!!! Я понял, почему мы беседуем в "разных плоскостях".
Рубрика этой темы "............7.7".
А Вы пытаетесь "нанизать" сообщения данной темы на ".........8.х".
Хотя, действительно, есть общие моменты в обеих системах.
И их имеет смысл обсуждать.
Но, постоянно тыкать, мне "восьмеркой" в глаз не надо.
Я уже писал выше, что не предлагаю своей системой (точнее, идеями из своей системы) заменить 1Су. Даже в начале темы написал - то, что сделано у нас это уже не 1С.
"Можно расшифровать фразу?"
Думаю, перед тем как писать "А потом второй, третьей, четвертой..." надо было именно об этом спросить. ;-)
"Почему в 8-ке не сделали, тоже не смогли?"
Если не сделали (я об этом не знаю) то либо не смогли, либо не захотели. Т.к. при наличии "трех уровней" можно было бы "изогнуться" и сделать журналы. А чего еще делать "среднему" уровню? ;-) Про 1С 8.х на сайте изготовителя написано:
"... при выполнении даже весьма сложных запросов программа, работающая у пользователя, будет получать только необходимую ей выборку, а вся промежуточная обработка будет выполняться на сервере...".
P.S. О!!!! Я понял, почему мы беседуем в "разных плоскостях".
Рубрика этой темы "............7.7".
А Вы пытаетесь "нанизать" сообщения данной темы на ".........8.х".
Хотя, действительно, есть общие моменты в обеих системах.
И их имеет смысл обсуждать.
Но, постоянно тыкать, мне "восьмеркой" в глаз не надо.
Я уже писал выше, что не предлагаю своей системой (точнее, идеями из своей системы) заменить 1Су. Даже в начале темы написал - то, что сделано у нас это уже не 1С.
... господа ... мне наш разговор напоминает разговор мастеров следующих профессий:
1. плотник
2. столяр
3. мебельщик
4. краснодеревщик
5. музыкальных инструментов
... один говорит я топором да стамеской всЁ сделаю, другой говорит что без ножовки не обойтись а третий говорит что вообще бы и лобзик с мелкой пилкой иметь ...
... пока не договоримся о "входных условиях" и "выходных данных" их количествах и точности вычислений, стоимости оного т.д. - всё будет разговорами ...
где-то и камаз молодец а где-то и велосипед красавец ...
... больше цифр, больше отчётов, больше вычислений - меньше скорость, больше программистов, труднее обслуживать, дороже обрудование ...
... вопрос - кто, где, как и когда сможет остановиться ...
... в СССР была создана гениально-простая-быстрая-точная-дешёвая СИСТЕМА учёта + финансовый анализ .... там где раньше работало 3-5 бухгалтеров теперь 12-15 + 1-3 программиста а про затраты и говорить нечего - при тех же обЪёмах выпуска ... а фактическую себестоимость как считали на конец квартала + 1 месяц так и считаем - раньше только были плановые цифры а теперь ... теперь и говорить нечего ...
... партионный учёт - игрушка ... у нас его не булы, нет и не будет ... не то разделение труда и не та дисциплина труда ...
... смЕЕЕшно-с ...
1. плотник
2. столяр
3. мебельщик
4. краснодеревщик
5. музыкальных инструментов
... один говорит я топором да стамеской всЁ сделаю, другой говорит что без ножовки не обойтись а третий говорит что вообще бы и лобзик с мелкой пилкой иметь ...
... пока не договоримся о "входных условиях" и "выходных данных" их количествах и точности вычислений, стоимости оного т.д. - всё будет разговорами ...
где-то и камаз молодец а где-то и велосипед красавец ...
... больше цифр, больше отчётов, больше вычислений - меньше скорость, больше программистов, труднее обслуживать, дороже обрудование ...
... вопрос - кто, где, как и когда сможет остановиться ...
... в СССР была создана гениально-простая-быстрая-точная-дешёвая СИСТЕМА учёта + финансовый анализ .... там где раньше работало 3-5 бухгалтеров теперь 12-15 + 1-3 программиста а про затраты и говорить нечего - при тех же обЪёмах выпуска ... а фактическую себестоимость как считали на конец квартала + 1 месяц так и считаем - раньше только были плановые цифры а теперь ... теперь и говорить нечего ...
... партионный учёт - игрушка ... у нас его не булы, нет и не будет ... не то разделение труда и не та дисциплина труда ...
... смЕЕЕшно-с ...
(280)
Александр.
В целом - согласен.
Однако есть ряд вопросов, где существует полное понимание "входных...выходных...".
Например, вопрос от Сергея: "общий журнал все в ступоре держит". И если, например, мне известна причина этого, с точностью "до машинной команды", почем бы об этом ему не сообщить? Его, же, этот вопрос интересует вторым пунктом к обозначенной теме на форуме...
Александр.
В целом - согласен.
Однако есть ряд вопросов, где существует полное понимание "входных...выходных...".
Например, вопрос от Сергея: "общий журнал все в ступоре держит". И если, например, мне известна причина этого, с точностью "до машинной команды", почем бы об этом ему не сообщить? Его, же, этот вопрос интересует вторым пунктом к обозначенной теме на форуме...
(281) ... именно поэтому и призываю к предметному разговору а не прениям на общую тему учёта ...
сначало нужна концепция, идея, задумка, технические характеристики, тогда есть смысл о чём-то говорить ...
ты... ту же не захотел свою версию выложить ... нет предметного разговора и его не будет до тех пор пока не появится некая заготовка и обоснование и технические характеристики ... секреты не нужны но нужна схема, структура ... тогда и в глубь можно идти ...
... если раньше в документе было к примеру 10 колонок то теперь до 30 ... да ещё и количество движений делает раз в 10 больше ... а уж про дублирование цифр и говорить не приходится ...
... принцип игрушки - железо всё спишет ... какой нынче самый популярный девиз внедренцев - это не программа медленная это у вас железо слабое ... да и сами вы тупые - без УУ живЁте ...
... вот-ссс ...
... вот ...
сначало нужна концепция, идея, задумка, технические характеристики, тогда есть смысл о чём-то говорить ...
ты... ту же не захотел свою версию выложить ... нет предметного разговора и его не будет до тех пор пока не появится некая заготовка и обоснование и технические характеристики ... секреты не нужны но нужна схема, структура ... тогда и в глубь можно идти ...
... если раньше в документе было к примеру 10 колонок то теперь до 30 ... да ещё и количество движений делает раз в 10 больше ... а уж про дублирование цифр и говорить не приходится ...
... принцип игрушки - железо всё спишет ... какой нынче самый популярный девиз внедренцев - это не программа медленная это у вас железо слабое ... да и сами вы тупые - без УУ живЁте ...
... вот-ссс ...
... вот ...
(282)
Александр.
Уже, вроде, и не обсуждаем "не захотел свою версию выложить ... нет предметного разговора ". На мой взгляд, всё уже сказано в части "концепции и идей" с моей стороны. Ждем от Сергея "некую заготовку". Лично, я хотел до Сергея донести не конкретную реализацию (мою) решения, а дать ему дополнительную информацию для размышления. И эта информация укладывается в три коротких абзаца...
Александр.
Уже, вроде, и не обсуждаем "не захотел свою версию выложить ... нет предметного разговора ". На мой взгляд, всё уже сказано в части "концепции и идей" с моей стороны. Ждем от Сергея "некую заготовку". Лично, я хотел до Сергея донести не конкретную реализацию (мою) решения, а дать ему дополнительную информацию для размышления. И эта информация укладывается в три коротких абзаца...
(284)
Да. Но.
Мне сообщать Сергею информацию о "проблема также в механизмах" в личке. Т.е. он пишет это в своей теме, а я ему в личке отвечаю. Так?
Я уже и так каждую свою фразу по десять раз перечитываю, перед "публикацией", на предмет "Моха" составляющей. Напишу, слово "журнал" и по полной своей САПе получаю...
Да. Но.
Мне сообщать Сергею информацию о "проблема также в механизмах" в личке. Т.е. он пишет это в своей теме, а я ему в личке отвечаю. Так?
Я уже и так каждую свою фразу по десять раз перечитываю, перед "публикацией", на предмет "Моха" составляющей. Напишу, слово "журнал" и по полной своей САПе получаю...
И новый документ не может быть записан в базу не из-за журнала документов, а из-за необходимости чего-либо блокировать для обеспечение не противоречивой информации.
- ''' чего-то я не понял... если я провожу например документ СписаниеТМЦ (Журнал.Складские) - то он застрянет из-за транзакции проведения документа например АвансовыйОтчет (Журнал.Авансовые) - хотя ни по составу справочников и журналов - эти два дока НЕ ПЕРЕСЕКАЮТСЯ, однакоже... общий(полный) журнал есть - он и будет причиной блокировки...
- или я не прав???
Владимир (hogik) пишет:
"Почему в 8-ке не сделали, тоже не смогли?" Если не сделали (я об этом не знаю) то либо не смогли, либо не захотели.
Ответ: потому что, общий журнал в 7-ке задолбал всех, включая Че бурашку :)))))).
"Почему в 8-ке не сделали, тоже не смогли?" Если не сделали (я об этом не знаю) то либо не смогли, либо не захотели.
Владимир (hogik) пишет:
P.S. О!!!! Я понял, почему мы беседуем в "разных плоскостях". Рубрика этой темы "............7.7".
Не совсем в разных. Вы рассказываете про чудесные изменения Вами чего то в 7-ке и говорите, что после этих изменений ве работает. В 8-ке все эти чудеса сделаны штатно. Чудес не наблюдаю.
P.S. О!!!! Я понял, почему мы беседуем в "разных плоскостях". Рубрика этой темы "............7.7".
Более того, стараюсь посмотреть на все это с точки зрения "идеальной" методы. Извините, опять ничего удивительного не нахожу. везде приходится работать, пересчитывать итоги или вещи им аналогичные или считать налету, теряя скорость.
Шёпот теней пишет:
там где раньше работало 3-5 бухгалтеров теперь 12-15 + 1-3 программиста
Может я что плохо помню, но раньше один бух вел чуть ли не один счет.
там где раньше работало 3-5 бухгалтеров теперь 12-15 + 1-3 программиста
Che Burashka Сергей пишет:
- ''' чего-то я не понял... если я провожу например документ СписаниеТМЦ (Журнал.Складские) - то он застрянет из-за транзакции проведения документа например АвансовыйОтчет (Журнал.Авансовые) - хотя ни по составу справочников и журналов - эти два дока НЕ ПЕРЕСЕКАЮТСЯ, однакоже... общий(полный) журнал есть - он и будет причиной блокировки... - или я не прав???
Именно. Застрянет он потому, что в таблицу "общий журнал документов" происходит запись в момент проведения. Можно пошукать точнее, но суть в том, что приходится тут блокировать всю таблицу. И по уму он должен на время проведения блокирнуть еще ряд таблиц, которые используются в обработке проведения.
- ''' чего-то я не понял... если я провожу например документ СписаниеТМЦ (Журнал.Складские) - то он застрянет из-за транзакции проведения документа например АвансовыйОтчет (Журнал.Авансовые) - хотя ни по составу справочников и журналов - эти два дока НЕ ПЕРЕСЕКАЮТСЯ, однакоже... общий(полный) журнал есть - он и будет причиной блокировки... - или я не прав???
Может сейчас напишу бред, но тут используется команда SQL INSERT. Чтобы корректно вставить запись, требуется на время заблокировать всю таблицу. Для смягчения этой ситуации в 8-ке общий журнал разбили на более мелкие. При проведении блокируется только таблица конкретного документа. И в один момент времени можно проводить 1 "разнотипный" документ.
(294) Не спорю. Но есть практика работы с базами данных вообще, из которой, судя по рекомендациям, следует именно то, что при конкурентной работе блокировать надо по минимуму, обеспечивая чистое чтение. 7-ка блокирует излишне. Это сказывается на многопользовательской работе.
Исходя из этого же и особенностей быстрого поиска по ключу следует то, что запросы надо делать "короткими" и четко по полям ключа (хотя бы по первым). СОЕДИНЕНИЯ (JOIN) для таблиц-"рабочих лошадок" - ввобще, ЗЛО.
Исходя из этого же и особенностей быстрого поиска по ключу следует то, что запросы надо делать "короткими" и четко по полям ключа (хотя бы по первым). СОЕДИНЕНИЯ (JOIN) для таблиц-"рабочих лошадок" - ввобще, ЗЛО.
(297) Давайте. Только я буду вставлять иногда комментарии типа "в 8-ке это сделано, но не помогло решению проблемы". Иногда буду пояснять, почему, по моему мнению, не помогло.
Пока для меня все прозрачно: там, где есть в движениях реальная зависимость данных записываемого движения от предыдущих документов (жесткая прослеживаемая связь) последовательности будут.
К таким жестким связям можно отнести Партию, иногда ГТД, списываемую себестоимость по ФИФО/ЛИФО/среднескользящей.
Связь отсутствует при учете только количества товара и суммы расхода, при учете по плановой себестоимости.
Алес гэмахт. ИМХО.
Пока для меня все прозрачно: там, где есть в движениях реальная зависимость данных записываемого движения от предыдущих документов (жесткая прослеживаемая связь) последовательности будут.
К таким жестким связям можно отнести Партию, иногда ГТД, списываемую себестоимость по ФИФО/ЛИФО/среднескользящей.
Связь отсутствует при учете только количества товара и суммы расхода, при учете по плановой себестоимости.
Алес гэмахт. ИМХО.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот