Well it works and the poor schmuck is the person I hired and trained and they are still there. The db is still being sold and making money. Since code will be r

Well it works and the poor schmuck is the person I hired and trained and they are still there. The db is still being sold and making money. Since code will be read more times than be written, I try to write it so that a junior version of me from 10 years ago could understand it, after waking up in the morning before the 1st cup of coffee :-) The best advice is really to keep it simple. Build the system of out small, isolated units with clear APIs between them. The API and components should be isolated at runtime, so they can be restarted or fail separately, as well as in the code - separate modules / files / libraries. That way looking at it can be easier to understand how everything fits together. The simple part wasn't just a platitude or a generalizing statement. A db is really a beast that can easily turn into a giant ball of spaghetti with a ton of features, settings and tweaks and never-ending list of bugs. A lot of work and thinking I did on it (including a rewrite after an initial prototype) was with the goal of making it simple by cutting unnecessary features.