10 - Data and Databases - Spring Data

springboot
JPA
Spring Data
Introduction to Databases with Spring
Author

ProtossGP32

Published

March 30, 2023

Introduction

From Spring official page:

Spring Data’s mission is to provide a familiar and consistent, Spring-based programming model for data access while still retaining the special traits of the underlying data store.

It makes it easy to use data access technologies, relational and non-relational databases, map-reduce frameworks, and cloud-based data services. This is an umbrella project which contains many subprojects that are specific to a given database. The projects are developed by working together with many of the companies and developers that are behind these exciting technologies.

Features:

  • Powerful repository and custom object-mapping abstractions
  • Dynamic query derivation from repository method names
  • Implementation domain base classes providing basic properties
  • Support for transparent auditing (created, last changed)
  • Possibility to integrate custom repository code
  • Easy Spring integration via JavaConfig and custom XML namespaces
  • Advanced integration with Spring MVC controllers
  • Experimental support for cross-store persistence

Examples of database types

SQL

  • Normalized: typed database
  • Very Structured: Less error-prone when dealing with its data as it is all very defined
  • Low scalability: relational databases introduce high coupling between tables
  • Relational database: tables linked by ID fields
  • Example: each Java entity has its own table and they can be joined using ID fields

NoSQL

  • Not normalized: database isn’t typed (JSON-style entries, documents)
  • High scalability
  • Fast query responses
  • Examples:
    • DynamoDB
    • MongoDB

Accessing data sources from Spring Boot

Add the appropriate Spring Data dependency to the project and configure the data source properties in the application.properties or application.yml file.

Database or store?

A datastore (store) is, as its name implies, a place where data is stored. The simplest example of a store is a flat file saved on your disk.

You can also save data in a database, in which the data is stored physically in files, but those files are managed by some, very often sophisticated, management system.

From this perspective, databases are a special type of datasore.

Not all NoSQL databases have a built-in “manager”, or their function is very limited, so the management is done in the application level. That is why you may see them just as another storage system. Simply speaking, simple NoSQL databases (for example, key-value) are very often referred as a store while those more complicated (graphs) as a database, but this is not a rule of thumb.

SQL

We can classify database-management systems according to the database models that they support. First large-scale used models, dominant in the market for more than 20 years, were relational databases, and arose in the 1970s.

SQL stands for Structured Query Language, and these databases where primarily used for writing and querying data. SQL databases uses Edgar F. Codd’s relational model based on tabular data representation.

NoSQL

NoSQL databases, also known as not only SQL, are non-tabular databases and store data differently than relational tables.

NoSQL databases come in a variety of types based on their data model. The main types are document, key-value, wide-column, document-oriented and graph. They provide flexible schemas and scale easily with large amounts of data and high user loads.

Denormalization: the act of copying the same data into multiple documents or tables in order to simplify/optimize query processing, or to fit the user’s data into a particular data model. This collides with the SQL approach, where there are no data duplicates.

SQL vs NoSQL

Comparative table

Concept SQL NoSQL
Data Model Relational Document, key-value, column-family, graph
Query language Structured Query Language (SQL) Query APIs, sometimes proprietary
Scalability Vertical Horizontal
Data consistency Strong Eventual
Transactional support ACID compliance Limited
Schema definition Required Optional
Query flexibility Limited Flexible
Join operations Complex Not supported
Data modeling Fixed schema Dynamic schema
Availability and Fault tolerance Low High