1
votes

I have created an XML Schema to support metadata management for relational databases. The scenario involves multiple operational systems, an operational data store, and a data warehouse, all connected by ETL processes. I have also generated an XML file containing some dummy metadata that validates using the schema. I'm a MarkLogic newbie, but I'm confident that I'll be able to load the XML Schema and the XML data file into MarkLogic, and that I'll be able to create XQuery code for analysis, etc.

But I'm uncertain whether I'll be able to achieve a key requirement using this approach, which is that users need to be able to browse the metadata. E.g., click on a database and see a list of tables, click on one of the tables and see a list of columns, then click on a column and get its datatype, definition, key information, etc. Can I get there using XQuery, or do I need to use Node.js or some other tool?

I'll be setting about gathering up the real metadata on these systems and working on the MarkLogic development in parallel, and I'd like to be more sure I'm headed in the right direction.

Thanks in advance for any advice.

2
Note to close voters: the question asked seems clear enough (at least, two people have found it clear enough to offer answers). And if all questions about the architecture of a system are too broad to count as questions about programming, then the world is doomed to (even more) badly architected systems. The topic is high-level, not broad; they are not the same thing. - C. M. Sperberg-McQueen

2 Answers

1
votes

Clients like Node.js ultimately end up executing server-side calls into the MarkLogic function library (which is exposed in both XQuery and Server-Side JavaScript).

So, by definition, server-side code can do a superset of what client code can do.

To work out the approach you want to take, determine which queries you will need to execute in the backend to support which views. The combination of matching sets of documents and extracting portions of documents is very flexible.

The best approach is to model one document for each cohesive entity.

For the UI that drives the queries and returns the responses, it's possible to implement on the server but the more typical approach is to provide the UI in a Node.js or Java middle tier that queries MarkLogic or (for more complex data processing) executes server-side code on MarkLogic.

Hoping that helps,

0
votes

Thanks in advance for any advice.

Read a bit on the principles of RESTful design; your desire for browseability is a good match for it. The principle of RESTful design most salient for your description is: every thing you want the user to be able to look at should have a URI. The user should be able to see a list of tables? Specify a URI for the list of tables. The selection of tables should depend on this or that piece of information? Parameterize the URI. The list should allow the user to look at the metadata for one table? Specify a URI for the metadata for each table; make the list of tables include (who would have thought it?!) a link to that URI.

Among the small avalanche of books on RESTful design that have appeared in the last few years I can recommend Richardson and Ruby's RESTful Web Services (O'Reilly); there are doubtless others that are good, too.

The only drawback I've experienced in implementing designs of this kind with an XQuery back end is that the queries are always so simple that it feels as if I'm not making adequate use of the power of the server. I keep fearing that the XQuery engine will get bored.