Even with the toy example it is visible, that the "more readable" code does not scale because one will need to read too much. With fixed set of the tables whatever is ok, but if the set of tables is growing all the time, it's better to invest time in building a mini-framework, which will solve the problem in generic way, maybe, using relational db introspection and/or declarative constructs, rather than creating a bunch of classes. On the other hand, a bunch of classes can also be used to bring functionality, which differs from the general way.

It's not about "DRY at all costs", but good solutions usually conform to DRY. To phrase it differently: DRY is not the goal, but usual sideproduct of the adequate architecture.