Doom Ported to SQL: The Classic Shooter Now Runs Entirely Inside a Database

> I was surprised how easy it is to express pretty complicated game logic in SQL. The game logic is just ~5900 lines of SQL.

I still think HN is taking major naps on the capabilities of contemporary SQL.

There are businesses so complicated that maintaining procedural code over the domain is largely infeasible. Implementing business rules in SQL can decompose the problem in ways that allow for a lot more people to interact with it at the same time.

When I was working in semiconductor manufacturing, we relied very heavily on stored procedures and SQL to operate the factory. Very little operational decision logic existed in code. We had hundreds of users who were inspecting and proposing changes to the same set of procedures. Testing this stuff was trivial because we replicated the prod DB every morning and experimented against live data directly. There was no gap between the information of the business and its logic. Most shops are not ran this way. They treat the database like some CRUD retrieval engine instead of the nexus of both the data and logic.

When people advocate for spending big piles of money with Microsoft, Oracle and IBM, they are generally going for something like the above. They want literally one system the business operates inside of. Spreading a solution across 10+ vendors and tools when you could do with one is borderline negligence depending on your role in the organization.