XQueryを使用したXML文書のコンテンツの参照

Question

私は、リレーショナルデータベースのメタデータ管理をサポートするXMLスキーマを作成しました。このシナリオでは、複数の運用システム、運用データストア、およびデータウェアハウスがすべてETLプロセスで接続されています。また、スキーマの使用を検証するダミーのメタデータを含むXMLファイルも生成しました。私はMarkLogicの初心者ですが、XMLスキーマとXMLデータファイルをMarkLogicに読み込むことができると確信しています。また、解析などのためにXQueryコードを作成できるようになります。

しかし、このアプローチを使用して主要な要件を達成できるかどうかは不明です。ユーザーはメタデータを閲覧できる必要があります。たとえば、データベースをクリックしてテーブルのリストを表示し、テーブルの1つをクリックして列のリストを表示し、列をクリックしてそのデータ型、定義、キー情報などを取得します。XQuery、 Node.jsなどのツールを使用する必要がありますか？

これらのシステム上で実際のメタデータを収集し、MarkLogic開発を並行して作業することについて、私は正しい方向に向かっていると確信しています。

アドバイスを事前にいただきありがとうございます。

Answer 1

Node.jsのようなクライアントは最終的にサーバーロジックを（XQueryとServer-Side JavaScriptの両方で公開される）MarkLogic関数ライブラリへのサーバーサイド呼び出しの実行に終わります。

したがって、定義上、サーバー側コードはクライアントコードが実行できるもののスーパーセットを実行できます。

取る方法を理解するには、どのビューをバックエンドで実行してどのビューをサポートする必要があるかを判断します。一致するドキュメントセットとドキュメントの一部を抽出する組み合わせは非常に柔軟です。

最良の方法は、各結合エンティティごとに1つのドキュメントをモデル化することです。

クエリーを駆動して応答を返すUIの場合、サーバーで実装することは可能ですが、より典型的なアプローチは、MarkLogicを照会するNode.jsまたはJava中間層にUIを提供することです（または、データ処理）は、MarkLogic上でサーバー側のコードを実行します。それは、何かアドバイスを事前に

Answer 2

感謝を助け願って

。

RESTfulデザインの原則を少し読んでください。ブラウズ可能性へのあなたの願いはそれに適しています。あなたの説明のために最も顕著なRESTfulデザインの原則は、ユーザーが見ることができるようにするすべてのものはURIを持つべきです。ユーザーはテーブルのリストを見ることができるはずですか？テーブルのリストのURIを指定します。テーブルの選択は、これまたはその情報に依存する必要がありますか？ URIをパラメータ化します。リストは、ユーザーが1つのテーブルのメタデータを見ることができるようにする必要がありますか？各テーブルのメタデータのURIを指定します。テーブルのリストにそのURIへのリンクが含まれている（誰がそれを考えていたのだろうか？）。

ここ数年に登場したRESTfulデザインの小さな雪崩の中で、私はRichardsonとRubyのRESTful Web Services（O'Reilly）を推奨できます。確かに良いものもあります。

XQueryのバックエンドでこの種のデザインを実装する際に唯一経験した欠点は、クエリが常にシンプルであり、サーバーの能力を十分に活用していないかのように感じることです。私はXQueryエンジンが飽きるのを恐れている。