Fauxton lets you run queries and view the results. What else can you do? CouchDB's query syntax is called Mango. This solution might do the trick, but it’s clunky and limiting. The other available option is to show exactly five columns, and choose which field each column displays. Frustratingly, there’s no scrolling left and right, so the columns just get squished together: Sometimes your documents all happen to have the same structure, but if there’s even a little variety, this gets impractical fast. In the table view, you can select "show all columns", meaning there's one column for every field found in any of the documents. For each database, Fauxton lets you view documents either in their native JSON or as a table. In all the databases we’re looking at, documents are written and stored as JSON. It runs as part of the server itself and is accessible by browser at /_utils. Fauxton is built on top of this API with each page representing an equivalent endpoint. Couch’s primary interface is an HTTP API, typically used through cURL. CouchDB's FauxtonĬouchDB is a mature database with plenty of features, but its GUI Fauxton (formerly named Futon) is pretty minimal. Let’s get started, going from most basic to most advanced. When you have many concurrent users, you'll want to use clustering to achieve high availability if you need to improve the speed of heavy queries, you'll want tools that help you resolve bottlenecks, and so on. Obviously, this all depends on your specific needs. MongoDB Tutorials and Articles: The Complete Collection. It’s especially important that the GUI provide event logs and performance stats for debugging and identifying bottlenecks.Ĭlustering - one rationale for the creation of the first “NoSQL” databases was the need for horizontal scalability, so we might expect the GUI to help visualize and manage a distributed database. But the cost of freedom is that you’re more likely to run into gotchas. Stats and metrics - to oversimplify, document databases give you more freedom than relational databases. Here too, each database has a different approach that needs to be learned. Visualizing how data is processed - indexes, projections, queries, and especially aggregations, like MapReduce, are easier to analyze and keep track of with flow charts and other visual aids.
This can be a hassle, but good GUIs can help you write queries and indexes well before you’re fluent.
Learning to query - each database we’ll look at has its own query syntax in lieu of SQL. So, how can groups of documents with different structures be displayed and compared in a compact way? The popular third-party MongoDB tool Studio 3T.Īnd RavenDB’s RavenDB Studio, which I’d argue is the best management GUI in the field.īesides the usual features a database management system should have, I want to see how each GUI handles the demands specific to document stores.ĭisplaying documents - unlike the rows in a relational table, documents don’t have to obey a schema. In this article, I want to compare the different ways GUIs have been implemented for three document databases: There’s a lot to learn and keep up with, and a much higher proportion of developers that are new to the field.
Document databases are a diverse group of technologies, relatively young, and rapidly evolving in different directions. This is even more important outside the familiar world of relational databases, where people generally know the score. When a system breaks in production, a good GUI shows you what’s going on under the hood, while a bad GUI leaves you guessing. One diagram is worth a thousand stack overflow threads, as they say.įor veterans, a GUI should not just expose all the functionality of the database, but simplify or automate routine tasks. When you’re looking for the right database, it’s easy to forget the part that will most affect your experience in practice: the user interface.įor new developers, an intuitive and "discoverable" GUI can be just as important as documentation.
0 kommentar(er)
