4 ms·
> “You don’t need an ORM, write your own SQL queries directly and create a beautiful domain driven design object model” leads straight into a project only the o
by vishnugupta 6y ago
> “You don’t need an ORM, write your own SQL queries directly and create a beautiful domain driven design object model” leads straight into a project only the owner will understand
Could you please elaborate why will this end up happening?
I've been on projects that had ~50 active contributors. All of them used plain SQL queries and used a library (don't remember which) only to map columns to Java types. Everyone understood table structure they were working on and its relationship with other tables. If they introduced a new query they were expected to run 'explain plan' first to understand the consequences and change the query if needed. I won't deny that it all needed a bit of shepherding by the senior engineers but the overhead was negligible. As an upside every developer was always up to date with the schema and precisely knew the performance consequences.
The mess you state is perhaps a byproduct of "get-big-fast" code bases?
- chrisandchris 6y agoHow do you deal in such a project with similar queries that fetch not all the same data? E.g. Query A retrieves an Author and a count of all the boks he has written. Query B retrieves an author and the title of the most recent book he has written. I see following options: - make two models, one for each query -> leads to a lot of similar models and code-bloat - make a base query and fetch additional data with an additional query -> leads to a lot of small queries that would sometimes be more performant as a single query