代替DBMSアーキテクチャとアプリケーション開発アプローチ

システムまたはアプリケーションの情報コアを作成するのに適したテクノロジープラットフォームについて説明します。 プラットフォームには、シンプルな高レベルデータモデルコンストラクターとそれを操作するための基本的なインターフェイスが含まれ、ロールベースのアクセスモデル、SQLクエリエミュレーター（CRUD）、APIをサポートし、任意のワークステーション（UI要素）を読み込んでデータを入力することもできます。



このプラットフォームには、無数の「デザイナー」とは根本的な違いがあるため、登場しました。 いくつかの違いは質の高いホリバーに値するもので、他の違いは開発者の生活を単純化します。 いくつかのアプリケーションは既にライブクライアントで動作しますが、そのタスクの動作例を示します。



ここでは、プログラミング言語を習得することなくWebアプリケーションを構築できます。MSExcelほど複雑ではなく、ビジネス用語と数式のみで動作します。 もちろん、データベースの原則を理解することは、より堅牢で大規模で機能的な製品を開発するのに役立ちますが、このサービスは、単純なソリューションの特定の知識を必要としません。 Excelで動作します）。

免責事項

現在、それは単なるサービスであり、データストレージとアプリケーション開発へのアプローチを実装する概念であり、その信者は同名のプロジェクトの小さなチームです。 このサービスは可能性に満ちているふりをするものではなく、まだ多くの仕事があります。今のところ、オリジナルのアプリケーションデザイナーのコンセプトを確認しただけで、製品を作成しており、全員と協力して開発する準備ができています。

インテグラル

積分は、データモデル（メタデータ）を指定し、データを操作するための基本的なユーザーインターフェイスを提供する、アーキテクチャを形成するコアです。 基本的なインターフェイスでは、いくつかの簡単なコマンドを使用してデータ構造（DDL）を管理し、6つのコマンドを使用してデータ自体（DML）を変更します。 これらのコマンドはユーザーには表示されません-ユーザーには入力フィールド、テーブル、ボタンのみが表示されます。 コマンドを知らなくても、基本インターフェイスを使用してデータを操作し、情報システムをすばやく作成できます。



サービスと外部の世界との相互作用の一般的なスキームは次のようになります。







カーネルは、データバインディング、単純な検証、整合性制御、データベース言語でのクエリの構築、型キャスト、その他の面白くないことをすべて行います。 転送または要求する必要があるデータ、実行する要求、結果のフォーマット方法をユーザーインターフェイスで指定するだけです。 もちろん、必要に応じて、ビジネスロジックに関連する部分でカーネルを調整することができます。



統合的な「プログラミング」は次のとおりです。

• プロセスパラメータの設定-ステージ、ロール、プロパティ、構造、フォーマットなど。
• クエリ自体の作成と変更を含む、データを選択および変更するクエリの作成。
• データの挿入ポイントを持つユーザーインターフェイステンプレートを作成します。

ユーザーはシステムにログインし、自分の役割に応じたメニューを受け取り、情報を表示し、データを入力し、クエリを起動し、所定の段階を経てプロセスを移動し、レポートを受け取ります。 システムとのすべての対話は、テンプレートで指定されたフォームを介して行われます。 これはCMSの作業と非常によく似ており、デザイナーが言うように、「最初のBitraのように作られました」。



作業には、基本的なインターフェイスが使用されます。これは、ニーズに合わせて補完および拡張できます。 基本的なインターフェイスの形式はGithubで利用でき、自由に使用できます-それらをブラックジャックと女性で完全に書き換えるか、単に必要なスタイルを「プル」してください。

データ構造

Integralアプローチの主な利点は、データモデルを構築して操作するためのツールです。 ここで、ビジネスのオブジェクトのダイアグラムをすばやく作成できます。必要に応じて、ダイアグラムをすばやく再構築できます。



最初に、いくつかのエンティティ（以降、オブジェクトまたはタイプと呼びます）を記述するデータベースを取得します。 Integralのコアは、その性質と動作原理をすでに知っています。 それらのいくつかがあります：

• ユーザー
• ユーザー役割。
• ロールに含まれるオブジェクト（ロールとユーザーを含むすべての統合オブジェクト）;
• オブジェクトへのアクセスレベル。
• クエリ（リレーショナルデータベースのSQLクエリに類似）;
• 要求フィールド（新しく作成されたものを含むすべてのシステムオブジェクトの名前）。

リストされたオブジェクトには、カーネルも知っているいくつかのプロパティがあります。 一緒に、初期コンテンツは最小限の機能を提供しますが、これはアプリケーションに必ず存在し、他のすべてを収集することができます。



構造はタイプエディタで作成され、すべて次のようになります。







オブジェクトの階層は次のとおりです。ロールがユーザーに割り当てられます。ロールには、それぞれにアクセスが割り当てられた複数のオブジェクトが含まれます。 Requestオブジェクトもあります-これはデータベースのSQLクエリに類似しており、関数、形式を適用してそれらの合計値を計算できるフィールドが含まれています。 ここでは、わかりやすくするために、オブジェクト間の矢印で接続を示していますが、タイプエディターでは、長方形のオブジェクトは矢印で接続されておらず、階層は、リストを下にした親の右側の子の配置によってのみ示されます。 これは、小さな図でのオブジェクトの従属性がすでに明らかである一方、大きな図では矢印は利便性を追加せず、画像を混乱させるだけだからです。



また、階層内での認識を容易にするために、参照とテーブルの詳細のみが表示され、メールや電話などの単純なものがタイプエディターの下部にあるリスト（アルファベット順）にあります。



上記のオブジェクトに加えて、Integralは空白のシートであり、このシート上で、必要なデータ構造と関係をスケッチできます。 リレーショナルデータベースに実装できる構造。 おそらくすでにご想像のとおり、Integral自体はIntegralによって組み立てられます。



オブジェクト（ビジネスの用語）を追加するには、名前を指定し、文字列、番号、ファイルなどの基本タイプを指定するだけです。 合計16の基本タイプが利用でき、そのほとんどがデータの表示を決定し、残りが動作を決定します-たとえば、コンテキストアクション。



ユーザーの生活を楽にするために、基本的なデータ型を可能な限り簡素化しました。 任意のタイプのデータ自体は、バイトシーケンスとして同じ方法で保存され、基本タイプは出力形式、比較と検証のルールなどを決定します。これはユーザーには表示されません。 たとえば、ユーザーは、各属性の小数点以下の文字数を事前に考える必要はありません。 任意の桁数の数字を入力できます。ほとんどの場合（小数点の前後10-12桁）、これは不要な質問なしで正しく機能します（デフォルトでは、SIGNEDには小数点以下2桁が表示されます）。 数値を目的の形式で表示する必要がある場合は、これらの形式を追加の詳細の形式でバインドし、ユーザーが作成したテンプレートで使用できますが、後で詳しく説明します。



型は対応する英語の単語で名前が付けられているため、プログラマーが作業を開始するのはより慣れ親しんでいます。 必要に応じて、タイプエディタで1つの参照を調整することで、それらを人間の言語に翻訳できます。 これまでのところ、Integralユーザーのカテゴリの型の値を理解するのに困難はありませんでした。ロシア語の代替言語を発明した場合、それらが表示されるのではないかと疑われています。 もちろん、MS ExcelユーザーにIntegralの操作方法を教える場合、エッセンスや小道具などの概念は使用せず、テーブル、フィールド、列などの単純な概念で操作します。



名前、電話番号、メールアドレス、住所を持っているクライアントと仕事をしているとします。 Integralのこれらの新しい用語はすべて、オブジェクト、タイプ、またはエンティティとも呼ばれ、この単純な形式を使用して追加されます。







Integralでは、すべてのビジネス用語が定義されています。 次に、ビジネスが処理するすべてのエンティティがそれらから収集され、データ構造を形成します。 電話、メール、住所などの一部の用語は既にIntegralにあり、独自の目的に使用できます。

必要条件

任意のタイプの名前をクリックすると、詳細を追加できます。







システムに既に追加したタイプのセット全体を自由に使用できます。 もちろん、必要条件を追加し、必要に応じて作成し、削除し、スワップし、必要な属性、計算値、エイリアス、デフォルト値などの最も簡単なルールを設定できます。 同じタイプを異なるオブジェクトに小道具として追加できます。



タイプエディタで作成されたすべてのオブジェクトはすぐに使用できます。これらのタイプのインスタンスを作成し、詳細を入力できます。 オブジェクトは、すべての独立したエンティティ、つまり、誰の詳細でもないタイプのリストの形式でディクショナリにあります。 オブジェクトタイプと同じ名前のアクセス属性は独立したアクセスディレクトリへのリンクであるため、リストにアクセスタイプが表示されます。 ただし、オブジェクトタイプとメニュータイプは、ロールタイプに直接従属するため、リストには含まれません。







ディクショナリオブジェクトのインスタンスは、テーブルの形式で使用できます。このテーブルにフィルタを適用して、必要なレコード（属性別）を検索したり、リストを削除したり、エクスポートおよびインポートしたりできます。 辞書の[ユーザー]をクリックすると、ユーザータイプのすべてのインスタンスのリストが表示されます。







テーブルのエントリを編集するには、このテーブルの最初の列の値をクリックします。この場合、最初のフィールドは「ユーザー」です。



注：削除、編集、エクスポート、詳細の可視性、およびオブジェクトの操作に関するその他の制限は、個々の詳細に対して正確なユーザーロールで設定されます。 オブジェクトの値とその詳細にマスクを適用して、値によるアクセスを制限することもできます。



新しいレコードを追加するには、最初にこのタイプのインスタンスの値を指定します。







次に、このタイプの詳細が入力されます。







タイプエディタで設定される最も単純なルールが詳細に適用されます。電子メールと名前は必須フィールドです。日付は現在の日付の自動計算値です。



タイプエディタには、エンティティ間の関係を作成できるいくつかのトリックがあります。

1. どのタイプでも、このタイプへのリンクを作成し、このリンクをプロパティとして使用できます-元のタイプのインスタンスへのポインタ
2. エンティティ要件（それ自体に要件がある）は、順序付きレコードを追加できる従属テーブルの形式で編集できます。

小道具-型参照

この場合、すべてがシンプルで馴染みのあるものです。カテゴリタイプを作成し、それをクリックして、「リンクの作成」オプションを選択できます。







タイプエディタで、カテゴリという名前の2つのタイプを取得します。タイプ自体とそのインスタンスへのリンクです。







詳細リストにはそのうちの2つもあります。リンクには矢印の形のプレフィックスが付いています。







参照属性を追加すると、2つの関連テーブルが得られ、Integralはそれらを階層に従ってタイプエディターに配置します（参照とテーブルの詳細はその親の右側にあります）。







参照属性にエイリアスを割り当てることができます（図では太字で強調表示されています）。たとえば、法人など、さまざまな意味を持つさまざまな詳細で同じディレクトリを使用する場合に便利です。 人は顧客、請負業者、荷送人などです。







他の登録済みタイプを必要条件として使用し、そのインスタンスのIDを数値の必要条件の形式で示し、このIDを編集フォームまたはレポートのリンクに置き換えます。 たとえば、人、車、建物、または著作権が保護されていることを確認できます。

小道具-従属テーブル

このタイプの小道具は、関連データ間の迅速なナビゲーションに便利です。レコードの配列をオブジェクトに従属させることができ、親オブジェクトを操作するときに常に手元にあります。 たとえば、Roleエンティティには、オブジェクトとメニュー項目のリストの2つの詳細が含まれ、それぞれに詳細があるため、Roleタイプの対応する属性に多くの値を設定できます。







データディクショナリでは、すばやく移動できるテーブルのセットのように見えます。1つの関連レコードではなく、配列のみが表示されます。 ロールからオブジェクトへの移行では、このロールに含まれるすべてのオブジェクトが表示されます。







タイプを作成し、詳細を追加し、2種類の関係を追加する上記の方法により、リレーショナルデータベースで可能なデータ構造を作成できます。

お問い合わせ

Integralでデータを操作するために、クエリデザイナがあります。 ユーザーのニーズの半分以上をカバーする最も単純なケースでは、必要なデータフィールドを単純にリストするだけで十分です。Integral自体は、タイプエディターで指定された関係を考慮して、クエリ内の対応するテーブルを結合します。



たとえば、役割に応じたサービスのすべてのユーザーのすべてのアクセスの選択は、データフィールドの単純な列挙に削減されます。 [ディクショナリ]メニューで、リクエストオブジェクトを選択します。







リクエストの名前を設定し、[追加]をクリックします。







作成されたリクエストの必要なデータフィールドに移動します。







リストからオブジェクトを追加できる空のフィールドテーブルが表示されます。 このリストは、サービスインスタンスに登録されているすべてのオブジェクトを含むため、比較的大きくなります。 ユーザーが必要です-選択、追加。







作成されたユーザーデータフィールドには、これまで必要のない多くの詳細があります（この記事の後半でそれらを確実に検討します）。 レコードをそのまま保存します。







注 ： 複合型に関する例で行われたように 、クエリデザイナーは、コンパクトで不必要な詳細なしで、より魅力的なビジュアルインターフェイスにラップできます 。 機能を損なわないように、基本的なインターフェイスでは意図的にこれを行いませんでした。



データフィールドのテーブルにユーザーの行が表示され、使用可能なオブジェクトのリストが削減されました。ユーザーに関連付けられたオブジェクトのみが含まれるようになりました。 問題のステートメントから必要な役割を選択します。







リストには、ロールを介してユーザーに関連付けられたオブジェクトとメニューがあります。 オブジェクトを追加します。







最後に、アクセス属性であるアクセスレベルの説明を追加します。







これで、クエリの準備ができました。4つの異なるテーブルの4つのデータフィールドが含まれています。







リクエストの名前をクリックすると、フィールドのリストからリクエスト自体のフォームに移動します。ここには、「生成」ボタンがあります。 このボタンは、プログラムされたコンテキストアクション（この場合は、このレポート（要求）のIDを持つレポートフォームの呼び出し）を起動するための必要条件です。







起動されたリクエストは、すべてのユーザー、ロール、オブジェクト、アクセスレベルに関するレポートを返します。







オブジェクトのテーブル間の関係については考えなかったため、このレポートを1分以内に作成しました。 これはかなり単純なレポートですが、クエリデザイナーの機能を反映しています。 レポートはフィールド値でフィルタリングでき、Excelにアップロードすることもできます。



サービスで作成されたオブジェクトはすべてデータサンプリングで使用でき、Integral自体が関連するすべてのテーブルをリンクします。 クエリデザイナを使用すると、インデックス、外部キー、およびユーザーのビジネスに直接関係しないその他の詳細を処理しながら、ほとんどすべてのSQLクエリ（再帰クエリなどのエキゾチックなクエリを除く）の類似物を作成できます。



場合によっては、SQLクエリを記述するときに行うことに慣れているため、テーブルを結合するための独自のルールを指定する必要があります。Integralではこれを行うことができます。 これについては、この記事の後半で説明します。

ユーザーインターフェイステンプレート

ユーザーは、基本的なインターフェースに加えて、Integralがデータを置換する挿入ポイントを持つテンプレートの形式で任意のフォームを作成できます。 データは、データベースからの要求によって選択するか、テンプレートを操作するコンテキストから取得できます。名前とユーザーID。 GETおよびPOSTを介して渡されるパラメーター。 上位および隣接ブロックのデータ。 グローバル定数など



テンプレートに基づいたHTMLコンテンツの処理はサーバー上で実行され、ユーザーのアクションごとに新しいページが形成されます。 最初は、インターフェイスには6つのフォームテンプレートしかありません。各操作モードに1つ、さらに1つのメインページがあります。



フォームには次の目的があります。

• 原則として、スタイルとメインメニュー（または複数）を含むメインページ。
• データ構造を表示するタイプエディター。
• 辞書-すべての独立したタイプのリスト。
• 選択したタイプのインスタンスのリスト（上記のユーザー、ロール、オブジェクトのリスト）。
• 型のインスタンスを編集するためのフォーム。
• レポート。

カスタムフォームは、[ファイル]メニューのメインディレクトリと空の初期フォームが配置されているテンプレートディレクトリに読み込むことができます（ウェルカムメッセージとIntegral User Guideへのリンクが含まれています）。







基本的なインターフェイスの他の形式を置き換える必要がある場合は、 Githubからダウンロードして同じフォルダーに入れることができます。



このドキュメントの執筆時点では、テンプレートで使用される挿入ポイントには次の3つのタイプがあります。

• テンプレートのレイアウトブロック。
• データフィールド;
• ファイル。

「ブロックのレイアウト」は、データソースがこのブロックに提供するレコード数に応じて、ゼロ回以上繰り返されるパターンフラグメントを定義します。ソースの名前はマークアップで示されます。 「データフィールド」は、データソースレコードから特定の値を挿入する場所を示します。 「ファイル」には、テンプレートのテキストが含まれます。テンプレートのテキストは、ファイルシステムで検出され、解析され、指定された場所に挿入されます。 ブロックとファイルのネストレベルはシステムに限定されません。



次の図は、基本インターフェイスページテンプレート（main.html-メインメニューページ）のHTMLコードを示しています。TopMenuブロックとFileブロックの境界線は緑色で強調表示されています。 パーサーがこのテンプレートを処理するとき、TopMenuリクエストのためにデータベースを参照し、データフィールドTOP_MENU_HREFおよびTOP_MENUを見つけようとするレコードのセットを受け取ります。 クエリの結果—レポート—は、グレーのフレームで図に示されています。 これらのフィールドの値は、中括弧で囲まれたこれらのフィールドの名前の代わりにテンプレートに置き換えられます。 図で灰色で強調表示されているテンプレートのフラグメントは、TopMenuセットによって返されるレコードの数だけ繰り返されます。 <！-Begin：...->および<！-End：...->タグ自体は結果に含まれません。







次に、パーサーは構造<！-File：a->を検出しますが 、その代わりに、パーサーによって以前に処理されたパラメーターaで指定された名前のテンプレートファイルのコンテンツが挿入されます。その結果、ページには、使用可能なユーザーロールアイテムで構成されるメニューと、以前に選択したメニューアイテムに応じた職場が表示されます。目的のオブジェクトをクリックすると、ユーザーは別のワークステーションに切り替えますが、同様にパーサーによってアセンブルされますが、Fileブロックに別のフォームがあります：







したがって、サービスを使用すると、アプリケーションインターフェイスの構造を構築し、リクエストに埋め込まれたロジックを適用してデータを選択し、このデータをフォームに入力できます基本的なインターフェイスまたはカスタムユーザーフォームを使用してデータベースに変更を加えます。



クエリ結果はJSONの形式で利用できるため、データベースとロールメカニズムを整理するためのIntegral機能に依存して、クエリを構築する独自のテンプレートエンジンを使用する1ページのアプリケーションを作成できます。 JSON形式のレポートを要求するには、レポートが呼び出されたときにJSONパラメーターを渡す必要があります。







タイプエディター、レポートビルダー、およびユーザーフォームは、他の開発ツールにはほとんど見られない機能の組み合わせを提供します。データブロックとそれらを埋めるためのルールは、完全なプラットフォームへの不可欠な要素を完成させます。これらすべてのツールを使用して、データモデルの機能と複雑さに制限されないアプリケーションを構築できます。



必要に応じて、Integralと、VueやReactなどの最新のリアクティブUI jsフレームワークのいずれかを使用して、単一ページアプリケーションを作成できます。



おそらく、読者は多態性、継承、カプセル化なしですでに少し退屈しています...気にしないでください、そして、以下のセクションのそれらは少し筋金入りです。

上記についてもう少し深く、より詳細に

Integralの概念的な機能の簡単な概要に続いて、私の意見では、このサービスの最も興味深い機能のいくつかについてさらに説明します。誰かがもっと知りたい場合は、40枚のシートの開発者ガイドがあり、サービスについて知られているほとんどすべてを説明しています。逆に、すでに十分な情報がある人には、結論に進むことができます。



サービスはかなり原始的な形で存在し、いくつかの瞬間は率直に言って素朴に見えることを思い出させてください。私たちはそれを見て、それに取り組んでいます。変更要求ログには、適切なレベルのサービスを提供するための500時間以上の作業が含まれるようになりました。

インデックス作成とデータ整合性

Integralでは、すべてのテーブルのすべてのデータにインデックスが付けられます。はい。任意の数の列を持つテーブルを作成し、そこに多くのレコードをロードし、任意のフィールドでデータをフィルター処理できます。選択条件に該当する場合、インデックスを使用して検索が実行されます。将来どのインデックスが必要になるかを最初に心配する必要はありません。さらに、Integralは選択肢を提供しません。すべてがインデックス化されます。



クエリデザイナは、適切なインデックスを選択して、レポート内のデータをフィルタリングおよびマージしますが、可能な限り関係、キー、インデックスについて考える必要はありません。その結果、クエリは、手動で構成されたインデックスを持つリレーショナルデータベースで行われるのとほぼ同じように実行されます。





このようなインデックスは、選択的にインデックスが付けられたデータベースよりもデータを保存するためのスペースを必要とします（2〜3回）が、開発とサポートのエネルギーと神経を節約します。これらのオーバーヘッドは直線的に増加し、場合によっては、GUIDと非正規化を備えた1Cプラットフォーム、または情報ブロックを備えたBitrixなどのCMSで、多くの複合インデックスを備えたデータベースにデータを格納するコストよりも低くなります。



インデックスとパフォーマンスに関する理論上のホリバーを繁殖させないために、テストベンチを展開しました、数百万件のレコードでどのように機能するかを見て、触れることができます。数百万のレコードと数十の同時クエリを持つデータベースのように、このスタンドは時々遅くなるので、そこでパフォーマンスの適切なアイデアを得ることができます。



積分は、データの整合性を維持する最小限の手段を提供します。たとえば、必要に応じて参照値が使用されている場合、参照値を削除できないようにします。オブジェクトのタイプと属性にも同じことが当てはまります。タイプまたは属性のインスタンスがある場合、またはリクエストまたはロールで言及されている場合は、タイプまたは属性を削除できません。追加されたオブジェクトの一意性もチェックされますが、これは最も単純な場合のみです。タイプエディタで一意とマークされたオブジェクトの一意でない値が追加された場合のみです。



トリガー、キー、制約などは、Integralのコアから意図的に取り出されます。また、たとえば、レコードのシステムIDなど、ユーザーから隠すことができるものはすべて隠されていました（これはプログラマーにとっては珍しいことですが、すぐに取得されました）。それでも、必要に応じて、システムから任意のIDを取得できます。場合によっては、たとえば、APIによる通信に必要なだけです。



Integralは、トランザクション、ロック、制限のメカニズムなどの技術的障壁を強化する方向に発展するのではなく、原則として競合を回避するような方法でビジネスプロセスのコンパイルを促進し、何が起こっているのかを透過的に把握することに注意する必要があります。比ur的には、エラーが発生した場合に手を打つよりも、単にユーザーが間違いを犯さないようにした方が良いです。この滑りやすいトピックについては、別の記事で説明し、より具体的な理論と人生の例に裏付けられます。

データ変更要求

積分は、要求の結果として選択されたデータに変更を加えることができます。そのアーキテクチャによりこれを行うことができるため、機会をつかまないことは罪です。デフォルトでは、変更は2つのステップで行われます：今後の変更のプレビューと確認。確認なしでリクエストを実行することもできます。



レポートデザイナでは、データフィールドの属性は「割り当て」です。この属性には、定数または同じクエリの他のフィールドの値から計算された式であるかどうかに関係なく、任意の値を書き込むことができます。この式は、クエリによって返されたレコードごとに評価され、指定されたデータフィールドに割り当てられます。



変更要求は、データを作成、変更、および削除できます。これは、たとえば、クライアントとの会議をスケジュールしたり、請求操作を実行したり、単に古いレコードを削除したりする必要がある場合に便利です。小さなデータ構造の例でこれがどのように機能するかを見てみましょう。

データ変更

最初に、2017年秋に契約が締結されたすべての顧客について、「Autumn 2017」というメモを書き留めます。 これを行うには、そのようなクライアントを選択するクエリを作成します。クエリは次のようになります。







リクエストは、2017年9月1日から11月30日までの契約日にフィルターを適用することにより、必要なデータを選択します。 結果は次のレポートです。







次に、これらのクライアントに対して、props Note（props“ Assign”）に新しい値を設定し、列名にきれいなヘッダーを付けます：







更新されたレポートを実行すると、このリクエストによってデータにどのような変更が加えられるかについてのヒントが得られます。







表示される「実行」列で、データがどのように変更されるかを確認し、クライアントDmitry Mのメモの古い値を失う可能性があるようです。これを防ぐため、既存のテキストをリンクするSQL言語関数を適用して「Assign」属性を変更します新しい。 MEMOエイリアスをこの列に割り当てます。このエイリアスにより、テキストフラグメントを連結するCONCAT（）関数にその値を代入できます。







これで、リクエストはまさに私たちが望むことをします







「実行」をクリックすると、リクエストは適切なレポートを発行してデータベースに変更を加えます。







辞書の顧客テーブルには、新しい顧客データが表示されます。







何か質問があるかもしれません：あるオブジェクトがレポートに2回以上現れた場合、どうなるか、それを変更しようとしています。 回答：オブジェクトは1回だけ変更されます。 たとえば、次のレポートでは、レポートのいくつかの行に記載されているクライアントノートを追加します。Integralは、クライアントごとに1回だけ変更を行います。







これは、データ変更要求を使用する非常に簡単な例です。 実際には、たとえば、テストサーバーにデータをアップロードする前にクライアントの個人データを難読化（個人化）するなど、さまざまなテーブルのいくつかの詳細を更新する必要がある場合があります。



このサービスを使用すると、さまざまなエンティティからのデータフィールドなど、必要な数のデータフィールドに新しい値を指定できます。Integralは、これらすべての変更を必要なテーブルに慎重にポストします。

レコードを追加する

次に、新しいレコードの作成を示します。 例：2018年2月1日正午までに「クライアント」ステータスのすべてのクライアントとの会議をスケジュールする必要があります。 次のクエリを作成します。







ここから取得したレポートには、作成中のレコードに関するヒントが表示されます。「実行」をクリックすると、会議レコードが追加されますが、リクエストを再開しても、作成済みのレコードが重複することはありません。







カスタマーミーティングディクショナリには、次のエントリが表示されます。

レコードを削除する

レコードを削除するには、空の値-""を割り当てます。 予定ごとに予定を削除する例は非常に簡単です。







積分は空の値でスペースを浪費しないため、レコードはすべての詳細と下位テーブルがあれば削除されます：

外部ソースへのクエリを使用する

この統合により、クエリ実行中にhttp（s）プロトコルを介して外部システム（サイト、API、ファイルなど）にアクセスできます。 これを行うには、レポートURLフィールドで外部ソースURLパターンを指定する必要があります（この例では、タイプエディターでタイプRequest to Reportに名前を変更しました）。 テンプレートでは、名前を角括弧で囲むことにより、レポートフィールドの値を使用できます。







さらに、レポート列を選択するときに、名前を付けると、これらの列の値がURLテンプレートに置き換えられます。







abn_URL関数は、フィールドの内容を、レポートの各行に対して計算された受信URLへのクエリの結果に置き換えます。 たとえば、SMSサービスプロバイダーのAPIへの上記の要求を実行した結果、送信されたメッセージの識別子を含むサービス応答を受信します。このメッセージは、名前[名前]の受信者に特定の電話[電話]に送信されます。







URLへのリクエストの結果は、その値を任意のフィールドに割り当てることでデータベースに保存することもできます。

複合型を使用したタスクの例

最後に、何らかの理由で1Cのクライアントに大きな印象を与えた例を示します。複合型のタスクです。 タスクは、さまざまなアナリストのコンテキストでオペレーションに関するレポートを作成することでした。アナリストの構成は、オペレーションの一連のアカウントに依存していました。 このレポートでは、わかりやすくするためにユーザーインターフェイスに小さなjavascriptを記述する必要がありました。この不名誉（すぐに汚い、すみません）を含むフォームはgithub： Aggregate Typesで入手できます。



そのため、各アカウントの分析セットを示すアカウントのチャートを示しました（図では、計画の断片）。







勘定コード表はIntegralにインポートされ、分析オブジェクト（詳細セットを持つタイプ）はタイプエディターで作成されました。例：







命名法-親要素へのリンクを持つ階層参照。



次に、タイプエディターで、アカウントDtとKtを使用してOperationタイプを作成しました。これに対して、有効な分析オブジェクトのセットが指定されます。







オブジェクトの空の詳細は、データベース内の場所を占有しません。 分析オブジェクトのセットが非常に大きい場合、詳細のリストを整理することはできませんが、コンポジションに複雑なタイプを追加できる特定の属性を使用してこれらのタイプを作成します。 それなしでもでき、ユーザーがアクセスできるすべてを追加できます。



操作を開始するときに、関連するアカウントとその実際のパラメーターに従って分析を設定できます。







次に、取引に関するレポートを生成します。このレポートでは、アカウントDtとCtに対して個別に関心のあるアナリストのセットを選択できます。 アナリティクスごとに、レコードを選択するための条件を指定できます（フィルターフィールド）。







アプリケーションのプロトタイプであっても、エンドユーザーにIntegralの基本的なインターフェイスを強制的に使用させたくないため、この入力フォームを彼のために設計しました。 実際、アナリストの割り当て中に、リクエスト「アナリストレポート」のデータフィールドでエントリが追加および削除されます。ディクショナリでの表示は次のとおりです。







このレポートは、選択条件を満たすアナリストの必須セットを持つすべてのトランザクションを選択します。 もちろん、顧客が必要に応じて、分析オブジェクトの詳細を詳細にレポートに含めることができます。



レポートの結果は、分析の各組み合わせの操作の合計です。

ビジネス志向

Integralの幅広いユーザー向けの主なタスクは、プログラミング言語やデータベース理論を使用せずに、または知らなくてもデータを直接変換する機会を彼に与えることです。 そのため、一時、SQL言語が登場しました。これにより、会計士は、人間の言語でデータを独立して操作できます。 私たちも同じように進みますが、ビジネスに関係のない何かをする必要があると、人は自動化ツールを使用できなくなります。



Integralのモットー：「Excelほど複雑ではありません。」 Integralは、Excelをより柔軟で安全なデータの保存および処理手段に置き換えることができます。 これがSaaSであると心配する人はいますか？ 彼が郵便物を郵便で転送せず、ググロドックス、つまりデータをウールにする方法を専門的に知っているサービスから自分自身と承認されたサービスに必要なすべての情報を取り出すサービスを保存しないかどうかを尋ねますか？



まず第一に、それは所有者がしばしば自分で開発を行うか、少なくともそれを管理しなければならない中小企業のサービスです。 ITコンポーネントは企業にとって重要です。ビジネスの俊敏性と柔軟性を決定するのはそれだからです。 コアでないトピックに気を取られず、必要に応じてすべてを完全にやり直すことができるように、すぐに作業を開始する機会を与えようとします。 会計原則は変更されましたか？ モデル全体を裏返し、余分なものを捨てて、正しいものを追加してください！ Integralを使用すると、これをすばやく明確に行うことができます。

なぜこれがすべて必要なのですか？

プログラマーは、あまり一般的でないものをプログラミングすることを常に夢見てきたため、大きな成果を上げるための時間は長くなります。



私たちのプロジェクトは、このためのツールを作成する試みであり、Integralチームは、低価格および中価格セグメントの応用開発に見られる大量のデータで実用的な操作性を達成することに成功しました。 「実用的な操作性」とは、次の基準を意味します。

• ボリュームと複雑さが増すにつれて生産性が低下する割合は、従来の方法で作成された情報システムの割合よりも高くなく、既存の設計者のそれよりも顕著に優れています。
• データモデルの作成と使用に関して「デザイナー」に固有の制限がないこと。
• プログラミング言語の知識の観点からエントリのしきい値を下げました（情報システムのアーキテクチャ基盤の知識は、最終的にここで正当な位置を占め、短期的な技術の専門知識はさておきます）。

Integralのコアは非常にコンパクトであり、私たちの計算によるデータの低レベルの作業は一般にハードウェアで実行できます。 さよならメルトダウンとスペクター。 hello import substitution ...予想外に？ 一方、長い間ITで根本的に新しいことは何も起きていません（量子コンピューターの謝罪者は私を許しますが、実際の応用にはまだほど遠いです）。 実際にそのようなことをしようとしない夢想家は悪いです。 サービスアーキテクチャは、既存のプラットフォームとは根本的に異なり、たとえば、オープンアーキテクチャIBM PCの出現など、ITの世界を変えることができると考えています。



このサービスはここ数年だけ積極的に開発されており、このような小さな（そして誰もがお金を必要とするので不安定な）チームでは、通常の製品の10年前に作業しなければならず、プロジェクトを継続するにはチームがすでに多くを犠牲にしなければならないことがわかります。 同時に、方向そのものに疑いの余地のない見通しがあり、特にこの記事を書くきっかけになりました。Integralアプローチを開発、改善、普及させる準備ができているすべての人と協力したいと思います。

参照資料

開発者ガイド



サービスのデータベースの評価コピーの登録： https : //tryint.ru