[ケース]--非構造化データのミッドエンドケース

I.はじめに

最近、プラットフォーム アーキテクチャに関する議論を目にしました。同社は非構造化データのミドル プラットフォームを必要としています。そのアイデアは、いつでも変更される非構造化データを保存できるようにすることと、ローコードのアイデアを導入することです。非構造化データは未知であり、さまざまなビジネスのデータが異なるため、より適切に使用するには、ローコードをできるだけコード開発せずに関連する需要の変化に対応し、迅速に反復してオンライン化できるソリューションが必要です。

1. 思考

プロジェクトのシナリオはすべて非構造化データと接触するため、より優れた/よりスマートな管理を実現するには非構造化データセンターをどのように設計すべきでしょうか?
まず、mongodb は非構造化データ情報を保存するために使用できます。
最も基本的な文書業務は、追加、削除、変更、検索を満たさなければなりません。
「追加」: ファイルを追加するとき、まず、対応するフィールド情報を取得するためにどのようなデータ構造をマッピングする必要がありますか? 非構造化データの特性は不確実です。異なるファイルで解析およびマッピングする必要があるフィールドは変わります。特定のフィールドを設定するのが難しいため、条件を満たすために。
「チェック」: 検索エンジン クエリが最も一般的です。非構造化データ フィールドは不確実であるため、特定のフィールド クエリを見つけるための検索クエリ メソッドの条件をコードに実装するのが困難なことがよくあります。ローコードの概念と非構造化データに基づいて、「チェック」機能を最適化および改善するには、より柔軟なソリューションが必要です。
ファイルを便利に管理する方法。
いわゆる便利な管理は、ファイル (PDF、Office など) に関するより多くの情報をより早く知り、一部の業務運営などを容易にするのに役立ちます。【「(非構造化)文書管理事例」がアイデアを提供します】

2. アイデア

おすすめ

転載: blog.csdn.net/xunmengyou1990/article/details/131269563