0%

Book Description

Every year, developers learn new frameworks and languages not only to enhance productivity, but also to stay relevant in an ever-changing industry. And yet there’s always a chance that tools you learn today won’t be around next year. So you end up wasting your time, and worse, you waste the opportunity to learn something more relevant.

This report examines the benefits of developing on a multi-model database that supports document, graph, relational, key-value, and other data models. Author Eric Laquer of MarkLogic describes tools and techniques for working directly with data as it arrives from the source, enabling your team to explore, on the fly, what a potential solution for a customer will look like.

By leveraging what you already know about modeling and indexing data, a multi-model database will help you apply data management to the DevOps model and move past the limitations of rows and tables altogether.

This report explores:

  • How multi-model database management systems support a data-driven approach to software development
  • Why applications that support data integration and analytic use cases can break a relational data model
  • Case studies of two Fortune 50 companies that successfully adopted multi-model databases
  • Why a data-driven approach requires collaboration among DBAs, sysadmins, analysts, and compliance and risk managers

Table of Contents

  1. Preface
    1. About This Report
    2. Major Points
    3. Acknowledgments
  2. 1. Introduction
    1. Data-Driven Approach
    2. Collection of Case Studies
      1. Fortune 50 Insurance Company Case Study
      2. Fortune 50 Bank Case Study
    3. Special-Purpose Solutions
    4. Developing a Broader Perspective on Data Management
  3. 2. Data Is Knowledge
    1. Questions to Ask Before You Begin Data Modeling
    2. Questions Developers Need to Consider
    3. Specialized Data Management
  4. 3. What Software Developers Want
    1. Freedom from Rigid Schemas
      1. Dynamic Schemas
      2. Selective Use of Schemas
    2. Ability to Handle Different Data Types
    3. Architectural Simplicity
      1. Polyglot Persistence
      2. Multi-Model DBMS
      3. Minimize Conversion
      4. Functionality
    4. Shaping Data and Impact on Other Roles
  5. 4. What DBAs Want
    1. ACID Compliance
    2. Minimal Schema Changes
    3. High Availability
    4. Fault Tolerance
    5. Questions to Ask Moving Forward
  6. 5. What the SysAdmin Wants
    1. Software-Defined Infrastructure
    2. DevOps and Serverless Architecture
    3. Storage Tiers
    4. Architectural Simplicity
    5. Considering a Multi-Model DBMS
  7. 6. Compliance—Risk Management Perspective
    1. Redaction and Field-Level Security
    2. Network Security Transitioning to Data Security
    3. Taking into Account the Needs of a System
  8. 7. What the Analyst Wants
    1. Extracting, Transforming, and Loading (ETL)
    2. Complete and Integrated
    3. Accurate
    4. Flexible and Timely
  9. 8. Focus on the Data
    1. Technology
    2. Process
    3. Skills
    4. Conclusion