November 15, 2017 at 9:05 am
The problem with allowing applications to talk with a database the same way they talk to an object or web service isn't so much about translating the mismatch between JSON and relational tables or tabular row-sets, but rather that the application programmers often fall into this RBAR (row-by-agonizing-row) pattern. They fetch one "entity" or "document", process that, and then fetch the next. As a DBA, you still have emphasize to them the importance of fetching everything that you need, and only what you need, in one call.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 16, 2017 at 8:37 am
Eric M Russell - Wednesday, November 15, 2017 9:05 AMThe problem with allowing applications to talk with a database the same way they talk to an object or web service isn't so much about translating the mismatch between JSON and relational tables or tabular row-sets, but rather that the application programmers often fall into this RBAR (row-by-agonizing-row) pattern. They fetch one "entity" or "document", process that, and then fetch the next. As a DBA, you still have emphasize to them the importance of fetching everything that you need, and only what you need, in one call.
I agree, though that's what's "easy" for most developers. They think in singletons, and they program in loops.
Changing that is hard, and until we were to force db work early and ubiquitously for developers, it always will be.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply