Конструктивный форум бухгалтеров Казахстана

Конструктивный форум бухгалтеров Казахстана
Текущее время: 16-10-2018, 13:14

Часовой пояс: UTC + 3 часа




Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 16 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: 24-09-2017, 05:36 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Учет видов и разрезов информации в базе данных.

Курсаков С.А.


Что такое «виды» и «разрезы» информации в учетной базе данных.
В учете предприятия не вся информация однородна и прямолинейна. Кроме смысловых разделений информации на справочники, документы, регистры, отчеты и т.д., существуют еще другие членения на виды и разрезы информации. Однако на текущий момент необходимость явного выделения «видов» и «разрезов» информации (термины условные) практически никем даже не осмыслена, а уж тем более нигде в программных продуктах не реализована. Попробуем объяснить, что это такое и зачем оно вообще нужно.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:36 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Текущие проблемы в части «видов» и «разрезов» учетной информации.
С самого начала внедрения учетных программ (90-е гг. ХХ в.) существуют и постоянно нарастают проблемы следующего вида.
Во-1-х, традиционное разделение («обрезка») инфомационных баз по годам очень неудобна в плане невозможности анализа многолетних непрерывных трендов для торговли, плана, бюджета, производства и т.д. При этом было бы очень желательно, чтобы можно было сделать так, чтобы и базу не «резать», и быстродействие не снижалось, и многолетние ценные тренды для целей практики анализировать.
Во-2-х, на практике часто возникает требование одновременного учета многих видов информации - торговой, плановой, бюджетной, прогнозной и других видов информации в одной и той же бухгалтерской базе. Предлагаемый обычно метод учета для этой информации - в отдельных, других, разобщенных с бухгалтерией базах данных - сильно неудобен и поэтому, как кажется автору, отдельные программы (неважно, для каких целей) не получили сколь-нибудь широкого распространения.
В-3-х, растет необходимость хранения нормативных данных в базе. В одной из предыдущих статей («Учет кодовых данных») автор писал о том, что количество и объем кодовых классификаторов постоянно растет, и эта тенденция долгосрочная. Чтобы ей соответствовать, необходимо держать в базе образцы кодов и нормативные кодовые данные. Опять же, как хранить нормативные данные кодов и реальные данные кодов без разрастания количества таблиц.
В-4-х, существует потребность хранения заказов и заявок (разных видов и для разных целей). Предварительные заказы (любителям новых смартфонов привет) являются мощным трендом и двигателем торговли, их важность неоспорима. Потенциальные заказы оформляются менеджерами как полупрогнозы-полупланы.
В-5-х, есть еще другие проблемы, но далее мы не будем углубляться – картина уже ясна.
И что же может предложить традиционная «классическая триада» для решения всех этих проблем? Ничего. Более того, застывшая «классическая триада» не предлагает также способов своего динамического расширения (без ресурсоемкой реструктуризации базы), и, таким образом, не имеет путей и планов дальнейшего развития и удовлетворения учетных нужд, не предлагает новых способов соответствия меняющимся требованиям времени, не имеет видения будущего и перспективы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:38 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Предлагаемое разделение учетной информации на «виды» и «разрезы».
Исходя из всех вышеприведенных соображений, автором предлагается переосмыслить, «переизобрести» «классическую триаду», и создать вместо нее «виды» и «разрезы» информации в учетной базе данных.
Что это такое? Сейчас объясним.
С точки зрения характера информации предлагается новое понятие - «разрез». Чтобы предварительно понять, что это такое, приведем примеры «разрезов учетной информации» (ниже они будут все объяснены). Это - факт (учет), бюджет, план, отчет, заявка, предварительный заказ, потенциальный заказ, норматив (нормативные данные), дополнение (поправка, уточнение), дубликат, прогноз. Этот список не окончательный, он может и должен обсуждаться, перестраиваться, динамически расширяться (естественно, также динамически нужно делать и поддержку списка «разрезов» на уровне кода). В старой «классической триаде» из списка «разрезов учета» явно был выделен только «факт», и он же занимал практически всю базу. Остальные разрезы учета, если они и существовали в том или ином виде, были затушеваны и хранились неявно, без их логического ясного симметричного и параллельного выделения. Подробнее это будет рассмотрено ниже.
С точки зрения смысла учетной информации предлагается новое понятие - «вид». Примеры «вида учетной информации» - метаданные, примерные данные (демоданные), архивные данные, индивидуальные данные, текущие данные, зарезервированные данные, удаленные данные, данные переноса сальдо, данные шаблона. Этот список не окончательный, он может и должен обсуждаться, перестраиваться, динамически расширяться (естественно, также динамически нужно расширять и поддержку на уровне кода). В старой «классической триаде» из этого списка «видов учета» наиболее явно были выделены «метаданные» (причем пользователь не имел к ним доступа), и «текущие данные». Остальные «виды учетной информации» были представлены разбросанно-хаотически, неявно, и слабо продуманно.
Впрочем, все это предлагаемое деление довольно условно. Что не отменяет революционный характер этих предложенных идей. Предлагается автором снабдить все (ВСЕ) таблицы учетной базы данных этими 2-мя новыми полями (вместо поля «классической триады»), и выстроить логику манипулирования данными, опираясь на «виды» и «разрезы» информации.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:39 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Вид информации «факт (учет)».
«Факт» - это основной вид информации учетной БД, и он присутствует в каждой таблице и каждой строке, которая отражает фактическую учетную информацию. Практически все время бухгалтер имеет дело именно с «фактом», с фактической учетной информацией. Это выглядит примерно так (для краткости поля записей базы данных ограждены косыми чертами):
Для проводки -
\ Факт \ дата = 23.03.2017 \ счет дебета = 1330 \ количество = 34 \ сумма = 67564 \…и т.д. Это означает фактическую проводку, то есть которая учтена реально.
Для заголовка документа -
\ Факт \ дата = 23.03.2017 \ вид документа = приходная накладная \ контрагент = ТОО «Альфа» \… и т.д. Это означает фактический заголовок документа, то есть того, что был реально учтен.
Для строки документа –
\ Факт \ товар = Мыло \ количество = 34\ …и т.д. Это означает реально учтенную строку документа.
Для таблицы справочника –
\ Факт \ наименование = Мыло \ единица измерения = шт. \ … и т.д. Это означает реально учтенную товарную единицу.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:39 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Вид информации «бюджет».
Однако «фактом» давно уже мало кто ограничивается. Многие предприятия ведут бюджетный учет доходов и расходов в том или ином виде, и пока обычно в «ворде-экселе». Для этих целей предлагается вид информации «бюджет» - это информация для целей бюджетирования предприятия, не следует путать ее с «госбюджетом». То есть точно также, как записываются реально учтенные обычные документы (образцы приведены выше), предлагается параллельно записывать «бюджетные» документы. Ранее бюджетная информация ютилась где-то по закоулкам базы, в специально выстроенных загонах-лагерях в виде различных бессистемных регистров, справочников, документов и т.д. Теперь же предлагается симметрично учетной информации точно также, абсолютно аналогично и параллельно, отражать и бюджетную информацию (разумеется, у тех предприятий, где это требуется).
Предположим, маркетолог предприятия полагает, что реализация по расходным накладным в будущем квартале составит 100 млн. тенге. Тогда это будет записано в базе так:
\ Бюджет \ вид документа = расходная накладная \ сумма = 100 млн. тг. \ …и т.д.
То есть предлагается не составлять какие-то псевдодокументы «Бюджет продаж» - совокупность расходных накладных вида \бюджет\ и будет бюджетом продаж. Если это возможно и/или нужно, то эти расходные накладные вида «бюджет» могут быть детализированы до конкретных товаров и конкретных покупателей.
А, например, для заголовка документа «Начисление зарплаты» бюджет будет выглядеть аналогично –
\ Бюджет \ вид документа = начисление зарплаты \ сумма = 15 млн. тг. \ и т.д.
Опять же, совокупность «Начислений ЗП» вида «бюджет» и будет представлять собой бюджет расходов по зарплате. Бюджетирование станет легким, простым и прозрачным для среднестатистического бухгалтера, не будет представлять для него трудности, так как будет вестись в тех же документах, в которых бухгалтер ведет учет «факта».
Естественно, здесь возникает масса нюансов. Например, нужно будет так продумать алгоритмы документов, чтобы учитывать, что, например, в «бюджетной» расходной накладной покупатель обычно не может быть указан, в бюджете зарплаты конкретные сотрудники также могут быть не указаны, и т.д. А кто говорил, что будет легко? Однако расширение «классической триады» до «видов» и «разрезов» сулит множество новых возможностей, которых у существующих программных продуктов «классической триады» просто не будет никогда.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:40 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Вид информации «план».
Для исполнения «бюджета» предприятия составляется «план», их не следует путать. Например, чтобы исполнить бюджет продаж (расходные накладные вида «бюджет»), предприятию нужно закупить товары (приходные накладные вида «план»). Информация вида «план» выглядит аналогично и симметрично -
\план\вид документа = приходная накладная\дата=…\сумма=….\,
\план\справочник = Работники\дата приема =…\ и т.д.

Вид информации «отчет».
Существует также такой вид информации, как «отчет» - в смысле отчет о неких выполненных действиях и/или событиях. Это могут быть отчеты мастеров, прорабов, МОЛ, отчеты по использованию доверенностей, денег – одним словом, такой информации на предприятии достаточно. И не всегда она попадает в базу (т.е. становится «фактом (учетом)» теми же датами, теми же названиями и теми же количествами-суммами, как приносят ее бухгалтеру. И ранее она также ютилась где-то на задворках, в «ворде-экселе» в лучшем случае, а зачастую в обычном бумажном виде. Предлагается отражать такую информацию в базе, например –
\отчет\вид документа=списание материалов\МОЛ=…\материал=….\кол-во=…\сумма=…\,
\отчет\вид документа=доверенность\товар=…\количество=…\ и т.д.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:40 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Вид информации «заявка».
Как внутри предприятия, так и между предприятием и его контрагентами циркулируют разнообразные заявки – на выдачу денег, на отпуск материалов в цех, на продажу товаров, и т.д. И если ранее вся информация по заявкам собиралась либо в «ворде-екселе», либо в каких-то узкоспециализированных редких программах, то теперь предлагается опять же параллельно и симметрично записывать заявочную информацию в учетную базу данных с видом информации «заявка» –
\заявка\вид документа=расходный кассовый ордер\сотрудник=…\сумма=…\ - это заявка на выдачу денег,
\заявка\вид документа=расходная накладная\покупатель=…\сумма=…\ - это заявка на покупку товаров, и т.д.

Вид информации «предварительный заказ (предзаказ)».
Предварительные заказы составляют мощный двигатель торговли во многих отраслях. Предлагается не игнорировать этот факт учетной жизни, а опять же параллельно и симметрично отражать в обычной учетной бухгалтерской базе, например –
\предзаказ\вид документа=расходная накладная\товар=…\сумма=…\
\факт\вид документа = приходный кассовый ордер \ покупатель=… \ сумма=… \ документ-основание = расходная накладная с видом учета «предзаказ»\, и т.д.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:41 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Вид информации «потенциальный заказ».
Аналогично «предзаказу» предлагается оформлять «потенциальный заказ», только по нему вряд ли будет оплата. «Потенциальный заказ» отличается от прогноза.

Вид информации «норматив (нормативные данные)».
Большой массив данных в базе является «нормативными данными». Это данные различных кодов, справочники, классификаторы, и т.д. Предлагается отделять их тегом «норматив» от обычных данных вида «факт (учет)». Тогда можно будет эти данные предлагать для подстановки отбором. Также будет легче эти данные содержать в актуальном порядке, и вести дальше при изменениях законодательства. На текущий момент «нормативные данные» обычно ютятся где-то в закоулках базы данных в виде экселеподобных таблиц, внешних файлов, либо данных, пробитых прямо в коде. Теперь же предлагается упорядочить это вид информации –
\норматив\вид показателя=Код ТНВЭД\товарная группа=…\значение=…\,
\норматив\вид показателя=МРП\дата=…\значение=…\, и т.д.
После такого изменения сопровождение и обслуживание «нормативных данных» станет гораздо проще, будет одинаковым и симметричным, также, как и обычных данных вида «факт (учет)».


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:41 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Вид информации «дополнение (поправка, уточнение)».
Некоторые виды информации предполагают дальнейшее уточнение, детализацию, поправки и т.д. Это, например, «бюджет», «прогноз», и т.д. Ранее все поправки, их смысл, дата, цель и размер безнадежно терялись, потому что были включаемы обычно в первоначальный размер показателя. Теперь же предлагается такие дополнительные движения учитывать отдельно, например –
\бюджет\вид документа=расходная накладная\сумма=…\,
\дополнение\вид документа=расходная накладная\документ-основание=…\сумма=…\
Предполагается, что такой вид информации позволит выявить ошибки, учесть поправки разных авторов, повысит прозрачность, выявит историю редактирования различных документов без ресурсоемкого версионирования всей базы данных, без ведения объемных логов всех действий, без истории изменений, без задач последующего анализа и разбора логов и историй.

Вид информации «дубликат».
Бывает, что некоторым контрагентам часто выписываются дубликаты счетов на оплату, счетов-фактур и других документов. Потом вся эта информация теряется, и сложно вспомнить, как относиться к данному контрагенту, опять же нужно привлекать ресурсоемкое версионирование для получения полной истории редактирования всех объектов базы данных, либо вести объемные логи истории всех действий с задачей их последующего анализа и разбора. Однако можно решить эту задачу гораздо проще, прямо так и записывая дубликаты в базе данных, например –
\факт\расходная накладная N 67\покупатель=…\сумма=…\,
\дубликат\документ-основание=расходная накладная N 67\, и т.д.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:42 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Вид информации «прогноз».
«Прогноз» отличается от «бюджета» и «плана», и тоже реально существует в жизни. Например, прогноз валютных курсов, прогноз цен, прогноз выручки, и т.д. Ранее опять же вся эта информация отражалась где угодно – в «ворде-экселе», «почте-магенте», в «сети-интернете», но только не в базе данных. Теперь предлагается делать это в учетной базе данных, например -
\прогноз\валюта=…\валюта-измеритель…\дата=…\значение курса=…\, и т.д.

На этом краткое рассмотрение «видов информации» мы заканчиваем и переходим к рассмотрению «разрезов информации».

Разрез информации «метаданные».
Разрез информации «метаданные» предназначен для разработчика, классы приложения опираются на коды элементов «метаданных». Ранее разрез информации «метаданные» выглядел совершенно обособленным от обычных данных («факт (учет)»), и манипулирование «метаданными» в пользовательском режиме было затруднено, если вообще возможно. Теперь же предлагается управлять «метаданными» симметрично, параллельно и тем же самым способом и в том же самом режиме, что и основными данными «факт» -
\метаданные\справочник «Виды документов» \вид документа=приходная накладная…\прочее…\,
\метаданные\справочник «Планы счетов» \план счетов=основной\код счета=1330…\прочее…\.
Такой подход позволит полностью исключить ресурсоемкую операцию реструктуризации базы и обновления метаданных в монопольном режиме, единственно доступную раньше при обновлениях. Также легко можно будет переносить «метаданные» между физическими базами, легко можно будет изменять «метаданные», корректировать, обновлять, контролировать, проверять и т.д.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:42 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Разрез информации «примерные данные (демоданные)».
Раньше приходилось создавать специальную отдельную так называемую «демо-базу» для демонстрации образцовых документов и операций в том виде, как их задумал разработчик программы. А зачем? Можно прямо в обычной рабочей базе сделать разрез информации «примерные данные (демоданные)» и записать те же самые образцовые документы, например –
\демоданные\вид документа=расходная накладная\покупатель=…\сумма=…\.
Легко настроить отчеты так, чтобы для показа демоданных бывшей демобазы алгоритмы отчетов отбирали только записи по разрезу информации «демоданные». Преимущества такого подхода очевидны – исчезает «демобаза» как класс, легче становится сопровождение, становятся прозрачными данные. Также повышается уровень безопасности – ведь ранее разработчикам приходилось полностью брать с собой базу клиента со всей его конфиденциальной информацией. Теперь клиент-пользователь может создать для разработчика «демоданные», а разработчик может выгрузить запросом только данные с разрезами «метаданные» и «демоданные», никак не касаясь конфиденциальных данных клиента.

Разрез информации «индивидуальные данные».
Большую проблему представляли ранее индивидуальные доработки для конкретных клиентов. Потом о сути индивидуальных доработок все программисты благополучно забывали, чтобы позже, при очередном глобальном обновлении (новые планы счетов, новые налоги и т.д.) все эти проблемы вдруг вылезли все и сразу. Разрез информации «индивидуальные данные» позволит сразу одним запросом получить все индивидуальные доработки на уровне данных таблиц, например –
\индивидуальные данные\план счетов=основной…\код счета=1330.67…\наименование=Клеи строительные…\прочее…\.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:43 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Разрез информации «текущие данные».
Это основной массив данных в учетной базе. Все эти данные вам хорошо знакомы, и обычно они являются фактическими (учетными) данными. Текущие данные составляют проводки и на их основе формируются отчеты, например –
\факт\текущие данные\вид документа=начисление зарплаты\сумма=…\,
\факт\текущие данные\вид документа=приходный кассовый ордер\сумма=…\, и т.д.
Также текущий данные составляют почти весь объем справочников (таблиц), например –
\текущие данные\наименование товара = …\артикул=…\.

Разрез информации «зарезервированные данные».
Желательно предусмотреть (зарезервировать) часть строк многих таблиц для дальнейшего развития программы. Например, в будущем могут появиться новые налоги, о которых мы сейчас не знаем, но которые нужно будет рассчитывать в программе, адресуясь к их заранее известным кодам, например –
\текущие данные\код=1\вид налога=НДС…\прочее....\,
…………………………………….
\зарезервированные данные\код=45\вид налога=зарезервировано…\прочее…\, и т.д.
При наличии заранее зарезервированных строк данных в будущем, если появится, предположим, новый вид налога «Налог с продаж», разработчик сможет изменить строку с кодом 45 следующим образом, и опираться на ее данные в расчетах –
\факт\текущие данные\код=45\вид налога=Налог с продаж…\прочее…\.
«Резервные данные» должны быть скрыты от обычных пользователей. Также, если администратор хочет скрыть (временно или постоянно) какие-либо данные от обычных пользователей, он может присвоить им разрез «резервные данные».


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:43 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Разрез информации «удаленные данные».
Издавна существует такой разрез информации, как «удаленные данные» (то есть «помеченные на удаление»). «Удаленные данные» играют роль аннулированных данных, хотя и называются по-другому. Предлагается использовать их в таком же названии, поскольку оно давно устоялось и прижилось –
\удаленные данные\вид документа=начисление зарплаты…\прочее…\.
Только «текущие данные» могут стать «удаленными данными».

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

До виртуальной обрезки -
\текущие данные\дата=23.07.2009\счет дебета=…\количество=…\сумма=…\,
…………
\текущие данные\дата=30.09.2016\счет дебета=…\количество=…\сумма=…\,
\текущие данные\дата=30.09.2016\счет дебета=…\количество=…\сумма=…\,

После виртуальной обрезки -
\архивные данные\дата=23.07.2009\счет дебета=…\количество=…\сумма=…\,
…………
\текущие данные\дата=30.09.2016\счет дебета=…\количество=…\сумма=…\,
\текущие данные\дата=30.09.2016\счет дебета=…\количество=…\сумма=…\,


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:44 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Разрез информации «данные переноса сальдо».
Однако виртуальную обрезку нельзя будет выполнить без вспомогательного разреза информации «данные переноса сальдо». Именно это разрез служит для переноса сальдо с «отрезаемого» периода на «оставляемый» период. Алгоритм расчета итогов и конечных остатков должен брать в расчет «данные переноса сальдо» плюс «текущие данные», оставляя без внимания «архивные данные». Тогда структура записей базы после виртуальной обрезки может выглядеть так –

После виртуальной обрезки -
\архивные данные\дата=23.07.2009\счет дебета=…\количество=…\сумма=…\,
\данные переноса сальдо\дата=31.12.2015\счет дебета=…\количество=…\сумма=…\,
…………
\текущие данные\дата=30.09.2016\счет дебета=…\количество=…\сумма=…\,
\текущие данные\дата=30.09.2016\счет дебета=…\количество=…\сумма=…\.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 24-09-2017, 05:44 
Не в сети

Зарегистрирован: 02-01-2012, 10:59
Сообщения: 685
Откуда: Астана
Разрез информации «данные шаблона».
Существуют различные шаблонные данные, нужные для более легкого заполнения документов, и прочих списков. Это могут быть, например, списки работников для начисления зарплаты, списки товаров для инвентаризации, перечни самых ходовых товаров и т.д. Зачастую подобные списки, составленные и отсортированные по различным, зачастую неформализованным критериям, не имеет смысла выявлять значениями реквизитов. Проще составить эти списки так, как их желает видеть пользователь, для более легкого подбора в различные документы. Все данные подобного рода предлагается помечать разрезом информации «данные шаблона», например –
\данные шаблона\вид документа=табель\отдел = склад\....перечень сотрудников…\,
\данные шаблона\вид документа=инвентаризация (выборочная)\...перечень…\.

Матрица взаимодействий «видов» и «разрезов».
Интересный вопрос представляет собой матрица взаимодействия «видов» и «разрезов информации». Из приведенного выше текста понятно, что не все виды могут сочетаться со всеми разрезами. Также, иногда виды могут быть не указаны – но разрезы должны быть указаны всегда. Не все виды могут переходить друг в друга, не все разрезы могут превращаться друг в друга.
Однако, это уже более сложная тема, да и размером статьи автор ограничен. Коснемся этого вопроса как-нибудь в другой раз.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Эта тема закрыта, вы не можете редактировать и оставлять сообщения в ней.  [ Сообщений: 16 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения

Найти:
Перейти:  

cron
Powered by Forumenko © 2006–2014
Русская поддержка phpBB