![]() Referential integrity isn't a problem that "Low Tech Ley" is trying to solve, it's a problem created by his solution to his actual problem. I see "Low Tech Ley" problem as wanting to be able to make a change to single micro-service without impacting the other micro-services. His micro-services are highly decoupled except when it comes to the DB, because they all reference the same schema. A schema change for one micro-service is in danger of propagating changes to other micro-services at the same time. His services are no longer independently deployable so he's sad. What is a better solution to "Low Tech Ley" problem without forcing him to give up his ORM that is polluting all his Java/C# code with schema details?ĮDIT: The bit I don't understand about "Low Tech Ley" solution is that after segregating all the data so that each logical database entity is the "responsibility" for a single micro-service, why does he still need to split the database up physically? He's already done it logically. While it's nice to have the extra check in the DB the work of determining appropriate foreign key values should already have been done in the application correctly, I don't think that's an unreasonable expectation. ![]() What about changes that don't go through the application? Suppose you raise a support issue and a junior technician sends you a script to fix it - who or what will do the checking then? What when the application vendor is taken over and a whole new group of programmers takes the code in a different direction and accidentally (or otherwise) leaves out the relationship checks? No, database integrity should be enforced in the database layer.Īlso how else do you find about the bad allocation of records? With the foreign key you get a nice logged error (at least in any sensible application) that helps you track down the misallocation.
0 Comments
Leave a Reply. |