このタスクは1C開発者によって長い間設定されてきましたが、現在、多少なりとも動作するメカニズムの出現に満足しています。 ただし、データベース自体にバージョンを保存すると、すぐにその成長につながります。 この記事はこの欠陥に対処します。

バージョン管理1C。
オブジェクトのバージョン管理メカニズムは、時間のコンテキストで情報ベースオブジェクトの変更を監査するために使用され、WHO、WHEN、およびWHAT変更の質問に答えることができます。 参照オブジェクトおよびドキュメントは、バージョン付きオブジェクトとして機能できます。 このメカニズムは、プログラム設定の形式で構成されており、Full Rightsロールを持つユーザーが使用できます。 セットアップは、メカニズムのアクティブ化と、ドキュメントおよびディレクトリのバージョンを収集するモードの設定で構成されます。
ただし、シルバーの裏地はありません。 時間の経過とともに、ボリューム内の変更されたレコードの数はメインデータに匹敵し、単純に「ギャップ」に入り、すべての合理的な制限を超えます。 これは、システムパフォーマンスの量に大きく影響し始めます。
この欠点を解消するには、このデータを撤回して個別に保存することが論理的です。 監査が必要な情報システムが複数ある場合、これはさらに論理的です。
この問題を解決するために、私たちのチームは次の機能を備えたソフトウェア製品を開発しました。
1.スケジュールに従って、バックグラウンドで変更されたオブジェクトのデータを収集します。 作業ベースには最後の変更のみが残り、「最後」の数が規制されます。 そのため、ベースの「膨らみ」をなくすことができ、同時に何かが発生した場合、破損したドキュメントをすぐに戻すことができます。

2.監査に関するレポートの作成(誰が、何を、いつ変更したか)。 本当に「安全」が好きです。

3.システムでこれまでに変更されたすべてのものと、変更されたオブジェクトのすべてのバージョンが別のデータベースの1つの場所にあるシステムは指定されたシステムからバージョンとログの両方を収集します。

4.ただし、変更を監査する必要がある場合は、全体像を把握できます。

一般的に、有用なシステムが判明しました。 一方では、変更の不確実性を排除し、他方では、「最後」を責める方法がないため、ユーザーを懲戒します。