We have an API application with 2 REST endpoints, and 2 separate applications writing (independent) tables to the same database to serve as backend for these 2 REST endpoints. You can think of this as an almost-microservices setup with shared DB server.
We want to use liquibase to manage the database tables from each of these 2 applications, but can't find any best practices guidelines about how to manage the changelog setup.
Options we are discussing:
Each application maintains a separate changelog table, with records for the table it maintains.
Upside - completely independent setup, and sharing DB is co-incidental.
Downside - The changelog table numbers will increase as we add more tables / applications to feed to the same database. Need to remember which changelog to use for development and look at for debugging.
Both applications share the same changelog table.
Upside - Single setup, can use the liquibase default. Easy lookup and maintainance.
Downside - Possible conflict / wait in case both applications try to deploy at the same time.
Can someone point me to best practices around this?
This topic is explained in details in the Liquibase University Course https://learn.liquibase.com/catalog/info/id:131.
Check out this Module 6 Tutorial - Managing Changelogs for a Shared Database for Multiple Teams in the course.
Related
Currently I have a monolithic application with some modules like financial and accounting. This application uses a single database and the modules are divided into schemas, so when I need to display the data on user interface or in a report I just need to do a simple query with a couple joins.
My question is, in a microservices structure where each module has his own database, how do I retrieve this data getting the same result as if I were in a single database?
When talking about splitting the database in the process of migrating a monolith to Microservices, there are some known patterns like:
The shared database
Database view
Database wrapping service
Database as a service
Seems the database view or the database as a service could be a candidate in this case, but of course no one better than you can decide which one is viable in your project.
I highly recommend you to have a look at chapter 4 of "Monolith to Microservices" by Sam Newman.
I’m building two applications that need to share some similar data but each will also have unique data. Should I build a separate database for each app or let each app access the same database.
I need the shared data to update automatically on one app if it is changed in another. I’m also using postgresql with react and express with the intent of having both apps be progressive web apps and eventually react native apps.
In general, I would think of this as:
Databases are the unit of backup and recovery.
Databases can contain multiple schemas ("schemata" ?) which are the unit for managing users and objects.
Based on your question:
I need the shared data to update automatically on one app if it is changed in another.
It sounds like you want one database and separate schemas for each application.
It sounds as if you will need to join the database from both applications in a single SQL query. In that case, use one database and multiple schemas to separate the data.
You could have one schema common that contains the data which is shared between all applications and then one schema per application.
Both has pros and cons. But i think keeping them separate will be better. Pro for one can be con for other.
Pros -
separate DB makes maintenance better,faster and easy.
performance wise separate DB is better.
Migrations of code will be easy.
Cons -
Auto synchup can be tricky if tables etc. are different.
If one process need to use tables from both DB, it will be an issue.
Good morning,
I am using an asp.net framework with an azure client database.
I am now creating another server on Azure to host databases. On this server, for each customer registering on the website (for which 1 entry is created in my first database), I need to create a database with 8 tables - identical for each customer.
What would be the best thing to map the ASP.NET ID to a new database? Which framework would you recommend?
Thanks
Rather than running a VM where you're going to have to manage a SQL Server installation and write a bunch of code to handle a database per tenant scenario, I highly, highly, highly recommend taking a look at Azure SQL's multi-tenant sharding support. All of this code is already written for you. And it's not that you're paying for one DB per client - check out elastic pooling.
You can read the docs here.
Also note, this option will scale very well.
I have done this three different ways: a database per client where I wrote my own code to manage sharding, a single database with a separate schema per client (a huge pain in the rear), and using Azure SQL sharding support. It's not just the issue of correctly separating client data. You also need to think about querying for reporting across all client databases, and managing schema changes. Under the first two options, if you change a schema, you get to modify N client databases. Azure SQL's sharding tools will manage this for you.
I'm currently developing a service for an App with WCF. I want to host this data on windows-azure and it should host data from differed users. I'm searching for the right design of my database. In my opinion there are only two differed possibilities:
Create a new database for every customer
Store a customer-id to every table (or the main table when every table is connected via entities)
The first approach has very good speed and isolating, but it's very expansive on windows azure (or am I understanding something of the azure pricing wrong?). Also I don't know how to configure a WCF- Service that way, that it always use another database.
The second approach is low on speed and the isolating is poor. But it's easy to implement and cheaper.
Now to my question:
Is there any other way to get high isolation of data and also easy integration in a WCF- service using azure?
What design should I use and why?
You have two additional options: build multiple schema containers within a database (see my blog post about this technique), or even better use SQL Database Federations (you can use my open-source project called Enzo SQL Shard to access federations). The links I am providing give you access to other options as well.
In the end it's a rather complex decision that involves a tradeoff of performance, security and manageability. I usually recommend Federations, even if it has its own set of limitations, because it is a flexible multitenant option for the cloud with the option to filter data automatically. Check out the open source project - you will see how to implement good separation of customer of data independently of the physical storage.
I have had my experience with MSSQL Server somewhat 6 years ago, so I have only basic knowledge of its workings now.
The problem I'm posed with is that of syncing the databases between two live CRMs (NopCommerce and Rainbow Portal-based one if anyone's curious) running on the same DB server. The data I'm interested in is spread out among 7 tables in one DB and 5 in the other one. The idea is to have two web applications with same data with updates in one instantly propagating to the other.
Each database has numerous triggers and stored procedures that are used to keep the data consistent.
I am not aware of all possibilities of SQL Server, so I am open to suggestions as to what is the best and quickest way to achieve the goal. Is it about writing more triggers? Should I create a "watcher" application? Is there some built-in mechanism for that?
Thanks!
You should look at SQL Replication, and / or using SSIS for the integration ETL and scheduling etc.
Triggers (especially cross DB) can be messy to maintain and debug - you might also consider loading data into a separate (third) staging database, before then propogating the data into your other 2 databases?
(Other alternatives include Synchronous and Asynchronous Mirroring, which would require the entire DB's to be in synch, and log shipping - also entire DB - which would be one way only, typically for redundancy - These aren't likely to be useful for your purpose though)
You might want to look at SQL Server Replication - http://msdn.microsoft.com/en-us/library/bb500346.aspx in particular Merge Replication