undefined | Better HN

0 pointsSulphurSmell3y ago0 comments

>the database is almost always the main cause of any performance issues

I would be careful with the term "cause". There is a symbiotic relationship between the application and the database. Or, if talking to a DBA...a database and its applications. Most databases can store any sets of arbitrary information...but how they are stored (read: structure) must take into account how the data is to be used. When the database designer can be told up-front (by the app dev team) considerations can be made to optimize performance along whatever vector is most desired (e.g. read speed, write speed, consistency, concurrency, etc). Most database performance issues result when these considerations are left out. Related: Just because a query works (ie. returns the right data) does not mean it's the best query.

0 comments

tragomaskhalos3y ago

As a corollary to this, there is the infamous:

Client/front end guys: "you need to fix this query, it takes 10 minutes to run and the front end is timing out"

DBA: "err, this query wants to return 50,000 rows"

C/FEG: "yes, and?"

DBA: "what in blue blazes is your UI, or a user, going to do with 50,000 rows?"

C/FEG: "oh - we hadn't thought about that ..."

SulphurSmellOP3y ago

Ok, story time. Worked on a near-real-time system that processed millions of rows an hour. Devs routinely did a "select " and pulled 100K rows into an array on a local client. And they sorted it there*. The DBAs never looked into these because a)no resource issue, b)no perf issues and (most relevant) c) no one complained. One day this silliness was identified, and a quick meeting with the devs and DBA resulted. SQL 101. As if by magic, the client app was suddenly 3X more performant. The devs were applauded and there was much happiness in user-land. Only the SVP knew the truth...we left the sun shining on the developers. It was a rough week.

j / k navigate · click thread line to collapse