3

I am currently working to replace a bunch of legacy applications. The first one is getting close to being released, which will mean I will be starting the second one.

Each application deals with a specific part of a sales process. Initial customer acquisition (with potentially very little customer data, with a lot of it being optional intentionally), through to actual quote/sale process, and then on to an application looking at how to get customers back into the beginning of the sales acquisition process.

Now I have built applications for many years, used different techniques, all with their pro's/con's, without really knowing the preferred way.

  1. One large database, re-used by all of the applications to share customer data etc. This can make it a lot of work to maintain, having loads of developers all working on the same schema and services, having a dependency to most likely have to release all applications at the same time following changes
  2. Database split per area (Customer, Sales, Business Hierarchy etc), gives a logical split, but they are all still used by all of the applications, yet joins for data across databases can cause problems unless you do cross-database joins/link servers etc
  3. Each individual application has it's own set of databases. This makes development of each application a lot quicker and simpler. Yet also gives a lot of duplication in data copying it across each application. Then any changes in data needs synced somehow with other databases. For some areas you could open up a web API to get to some data between them, but a lot of the time you may end up having to read from one database to use that info to get more info from another etc rather than doing simple quick joins.

Can anyone give some info on the correct way? Yes, things can possibly be subjective, but I'm sure one of these ways would be more recommended than the other.

2

Microservices are the current trend, and they would roughly correspond with your third choice. You can spend a lot of time getting sucked into the literature around microservices, but yes, you will definitely contend with some degree of data duplication and possibly performance issues when compositing multiple microservices into a usable product.

Ultimately there isn't a right or wrong answer. Take the microservice literature with a grain of salt. They aren't always a good choice.

  • I completely understand using them if you can get a clear separation. In practice I'm finding it hard to think about implementing something like that when most screens would need a combination of data between them that are all related. – eyeballpaul Mar 9 '15 at 22:20
2

Build a data layer that matches your DB in a shared assembly. You can the have each of the business layers reference it (the data layer could be all interfaces to keep implementation separate). Then build out each of your use cases in the relevant business layers. You'll likely have a fourth business assembly which contains objects which implement shared use cases.

  • This would mean having cross dependencies across all applications. Which sounds a little similar to option 1. Simple to architect and build. But a nightmare to maintain across a large team. – eyeballpaul Mar 10 '15 at 8:36
  • @eyeballpaul why would your developers be changing the database? Shouldn't there be a DBA responsible for coordinating those changes? The applications shouldn't be tightly coupled to the persistence layer anyway. – RubberDuck Sep 6 '15 at 4:27
  • @RubberDuck in every company i've worked at developers are always the ones changing the db, the team just moves too fast to have a dba (who has other responsibilities and dbs to worry about) control this, they just end up an impediment. As far as tight coupling goes, at some point something has to connect and push data in and pull it out. And at some point trying to abstract is costs more than a certain level of coupling. – Andy Sep 6 '15 at 16:15
  • Fair points @Andy. For the record, I agree with your answer. – RubberDuck Sep 6 '15 at 16:16
  • @eyeballpaul at the end of the day, the db is a shared resource that something has to talk to, and at some point the abstraction costs more than the coupling. Put a web service around your db, but as the schema changes you'll build more and more service calls so you don't have to change the app using the db. That builds up over time and at some point you'll need to scrap the older calls and update your apps or be crushed in maintenance costs. You'll pay at some point, the only question is when. As you go, or stop all development to pay a now huge technical debt. – Andy Sep 6 '15 at 16:22
2

Schemas are a middle road between different databases and the drawbacks of having different databases. You can have your Customer and your Sales schemas, keeping them totally independeent or mixed as needed.

That gives you (2) without the major headaches with different databases: joins are in database, setup is easy (no linked servers), the data is all kept together (depending on size and usage this may be either positive or negative).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.