Hacker News Reader

A long standing interview question I've used is "draw us an ERD for this domain" (orders/customer/products).

It's what at first is a seemingly simple question to start drilling into understanding of systems "so if I was going to do X, what would you change in your ERD?" "how about if scenario Z was going to happen, would you change anything?"

Strange how every now and then you get a "system architect" that can't answer that one.

View on HN

That's usually because the architects don't give a shit about the storage model and recognise that the external interface/contract is far more important and that can be mapped to whatever schema supports the model. That's their domain. All they see is: "how can we ensure that this whole thing still works when someone does scenario X".

The schema is almost 100% irrelevant to us and we have nearly 2000 tables in our system. We have two hibernate implementations which put that all behind a testable interface: something SQL can't give you on it's own.

I don't envy your 2000 tables. Or hibernate, but if you have something that works for your team (and is testable) I'm not about to complain. As an architect, I will say that I do care about the storage model, but I'm obviously coming from a different place.

Reply on news.ycombinator.com