Anything where there is calculations, multi-step business process, regulations, complicated business language which takes time to understand is in use.
You first step in implementing in a feature is understanding the business domain with the help of people who know it well, then modeling it in the core of the application.
I'm currently working in the retail and warehouse distribution domain.
It is surprising how often all these things get reduced to bunch of relational tables with slightly non trivial integrity constraints because sooner than later there will be something that is outside of normal bussiness processes and thus requires exceptions in all these rules.
Essentially all big ERP packages follow the model of bunch of relational tables directly exposed to user with bussiness rules and processes as an afterthough. One can say that this stems from historical reasons, but unforeseen usecases that have to be somehow handled right now are also significant reason.
Having worked on ERP systems, I find the dB often becomes a major bottleneck because of this reason.
You end up creating a really beefy single database, with tons of ram, infinityio etc
We have a bunch of different DBs for specific purposes. Some have to be super fast for reading, some just store streams of events, others need to maintain consistency.
I'm in a similar niche. Anything you could recommend (books?) to learn more about the organization/design of large amount of data (i.e. choosing the right DB for Inventory Management System, designing complex schemas, etc.)
You first step in implementing in a feature is understanding the business domain with the help of people who know it well, then modeling it in the core of the application.
I'm currently working in the retail and warehouse distribution domain.