CHAPTER 4 Design Documents In Chapter 3, we examined the basics of creating documents in a CouchDB database. Documents are where you store the data, but the only way to get the information back out from your documents is to know the document ID you used to store the document. There are a few different issues with the document structure that you may want to consider, such as enforcing document structure, handling document validation, and searching and querying the document data. The key to all of these different types of information, and many others, is the design document. Aside from the core document storage, the design document is probably the most important component of your CouchDB database. Design documents contain all of the database logic about the document you are storing. Think of the design docu- ment as the glue that turns each of your documents into the format or structure that you need for your application. The different components of your design document are written using JavaScript and they are executed within the CouchDB application. Because they are code, you can perform almost any action that would perform with JavaScript on an object. This means that you can select fields and components, perform test, reformat, calculate, and many other operations. This is useful as the different components of the design document work together to support the different formatting, indexing, and other procedures. To be more specific, a design document provides the following: Views Views are functions that take your document data and produce searchable lists of information based on the document's contents. Views are incredibly simple yet also very powerful and provide the main route of entry into your data for infor- mation for which you don't know the document ID. Shows A show converts a single document into another format, usually HTML, although you can output the document in any format, including JSON or XML, to suit your 37