4 ms·
I don't think the main advantage of this is switching databases. It's switching mindset. Lots of developers think database first, then build on top of that. Th
by UK-AL 9y ago
I don't think the main advantage of this is switching databases. It's switching mindset.
Lots of developers think database first, then build on top of that. That's good for simple crud apps.
For complicated apps you should think domain or business problem first. Model your domain, make it good for reasoning about your business issues, and then afterwords think about persisting that to a database. You domain is your application core, database persistence is a technical issue outside of that core.
- jl6 9y agoCan you give an example of an application core where the database is just a technical issue?
- UK-AL 9y agoAnything 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.
- dfox 9y agoIt 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.
- UK-AL 9y agoHaving 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.
- skazka16 9y agoI'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.)
- agentultra 9y agoBelieve me, I do think in terms of business domain problems first. One of my customers' primary concerns is ensuring that their data is consistent. Always. They make very expensive decisions based on the consistency of that data. If they have to shut down a plant because a value was off they lose millions of dollars. I see our customers' data as our core and any code we write as a liability. We're constantly looking for ways to reduce our liability and ensure our customers' data will always be consistent. We push all of our business logic down to the database layer where the RDBMS server is responsible for ensuring its consistency and integrity. While we're not perfect we do have some business logic in our web processes. However for the most part the job of that component is to parse HTTP queries into queries on our public schema. If we wrote business rules into our software it would be very difficult to verify them, search for them, and keep track of how they've changed over time. It's also too easy for a programmer to make an error which could cause our customers' data to enter into an inconsistent state or worse. We avoid that as much as possible.
- UK-AL 9y agoWell we have gone past the point where running on a simple master/replica database is an option. We are distributed.
- agentultra 9y agoEveryone is writing distributed systems whether they acknowledge it or not these days.