views:

208

answers:

3

I'm trying to get my team to think about only asking the database to do things it can do really well. I believe that when they stop thinking of the DBMS as an omniscient, omnipotent being and start treating it as a useful--albeit dumb--tool, they can begin to approach optimization and database design with the right attitude. That got me wondering: what types of operations does a modern database excel at? I'll start the list with the obvious tasks:

  • Join using indexes
  • Filter using indexes
  • Order on a minimal number of columns

Any others you can think of?

EDIT: Feel free to add database anti-patterns as well, such as:

  • Storing and manipulating binary files
  • Handling hierarchal data (most databases)


Note for the picky: I do know the distinction between a database and a DBMS, but most people don't know (or bother) to recognize it, so I'm intentionally interchanging the concepts.

+5  A: 

One important one that you missed was aggregate functions: sum, average, min, max, count, etc. (At least, the database should be really good at doing min, max, count on indexed columns).

Mark Rushakoff
There's about six aggregate functions which a RDBMS does, and they only operate on numbers. Not exactly generic.
Justice
Thanks, Mark! I added "aggregating numeric columns" to my presentation.
GuyBehindtheGuy
+4  A: 

well, there's the most obvious one:

store a ****load of information in a convenient, organised and memory efficient manner.

pstanton
+1  A: 

To add to Mark Rushakoff's answer, it can manipulate the data, using several aggregations and groupings, to format and prepare the data that you need.

For example, in MySQL, I had a query that would select all the users that were logged, and the number that logged in for each time of day (24 hour clock), for a time period, to see when the highest load was.

The database will tend to be faster at doing these manipulations than an application, but these complex queries are very dependent on profiling and optimizing them.

Formatting the results is important. There is no reason for me to have to turn a datetime into a string when it can come back as a string, formatted as needed.

James Black
Proof that the database can format a `DateTime` column into a string faster than application code? I can counter that spurious claim with one of my own: a `DateTime` will come back as 8 bytes, whereas a formatted string can come back as significantly more than that. I am highly skeptical about using the database to perform end-user formatting. Separate your concerns.
Adam Robinson
I have found that it didn't make sense to do a lot of formatting on the application side when the database could do it, esp since the database server was far more powerful than the webserver was. It simplified the application code, and took out some possible errors.
James Black
Formatting your values on the database side eliminates the ability to do culture-specific formatting or allow for variations in things like time zones; that's just for `DateTimes`. Overall, doing database formatting makes your code specific to a particular application, excluding the possibility of any real code reuse. I would be interested to see actual benchmarks that showed that formatting the data on the database side was appreciably (or even measurably) more performant than application-side formatting. Database optimizations like indexes and statistics can't be used for formatting.
Adam Robinson
For me the simplification of my application was worth it, but as I mentioned, in my case there was considerable different in power between the two computers, so my numbers would be different than others. All my clients were situated at one of the largest universities in the country.
James Black