For your business application with devonfw you need to choose the right database. In devonfw we are not biased for a particular product so you have the freedom of choice.
The classical and well-established form of a database is a relational database management system (RDBMS). In devonfw we recommend to use an RDBMS unless you have specific need. However, in case you have the need for big data, graph-data, BLOB focus, or schema-less dynamic data you can have a look at NoSQL options but be aware that these may be experimental and are not fully supported by devonfw.
In devonfw we are not biased for a particular RDBMS so you have the freedom of choice. Here are the most common options:
-
SAP Hana (high performance in-memory, many advanced features)
-
Oracle (most established, well featured for enterprise)
-
PostgreSQL (great open-source RDBMS)
-
MariaDB (true OSS successor of MySQL)
-
MS SQL Server (best choice for Microsoft and Windows dominated IT landscapes)
Please click on any of the above choices and go to the according guide to find specific detials such as client/driver.
While not (yet) officially supported and recommendet there are also interesting NoSQL (Not Only SQL) databases that could be an interesting alternative. Please be aware that you will typically not be able to use JPA (and hibernate). Further before choosing a NoSQL database you should check the following aspects:
-
Is the database of choice reliable and mature enough for your project?
-
Can the operators of your product support the database of choice properly (provisioning, administration, backup, scaling & clustering, monitoring, etc.)?
-
Does the database of choice meet the requirements of your project (ACID vs. eventual consistencey, CAP theorem)?
There are good reasons to choose a particular NoSQL database in specific cases (e.g. extreme demand for big-data, throughput or scaling). But as indicated by the questions above you need to be fully aware of what you are doing. NoSQL databases can be schemaless (untyped, dynamic & flexible) and/or schemaful (typed, structured & strict). Furhter, there are different types of NoSQL databases that are discussed in the following sub-sections:
Column NoSQL databases are more related to a regular RDBMS with their tables and columns. However, they typically do not offer relational support with joins to the same level as you expect from an RDBMS. Therefore, you have to carefully design your data-model upfront with the all the knowledge how you later want to query your data.
The most prominent options are:
As indicated by the name, a key-value database stores objects as key/value pairs similar to Properties or Map in Java.
The most prominent options are:
A document database is similar to a key-value database, but it stores objects in standard structured formats such as XML, JSON, or BSON. Therefore not only flat key/value pairs but even trees of hierarchical data can be stored, retrieved and queried.
The most prominent options are:
If the connections (links/relations) between your data is key and an RDBMS is just not flexible or fast enough for your plans, then a graph database can help you. They are very strong on storing and querying complex connections between entities. For queries there are even specific standards and languages like Gremlin.
The most prominent options are:
In addition to the above types there are some NoSQL databases that are hybrid and combine the features and aspects of these types. While as an architect and developer you might love the idea to get all in one, you have to be careful with your choice. If you do not exactly know your problem, you are not ready to make the right choice for your database. Further, you might still be best-off with an good old RDBMS if you need to address multiple aspects together. Anyhow, for experiments, PoCs, or small microservices with little risk it might be a great idea to choose a hybrid NoSQL database. If you have collected very positive, profound and productive experience with such product you can grow on it.
The most prominent options are:
-
OrientDB (object-oriented, hyper-flexible, column- and graph-based)