3 ms·

In practice, the answer is not always obvious. Benchmarking multiple queries / approaches is generally worthwhile if performance is important.

by soora 13y ago

kabdib 13y ago
... annnnd then the database technology changes, and your benchmark results of three years ago are now actively hosing you. Or you have to change databases but you can't because you embedded a lot of logic in your database layer that can't be easily ported (somewhere, a salesman for your current database product is crying tears of joy and shouting his cash-register shout, "Ka-ching! Customer lock-in! Ka-CHING baby!". Avoid these people). Unless you have really compelling reasons to get snuggly with a particular vendor's technology, be conservative. [This still applies if you're using a "free" database engine; you're just not paying MS or Oracle or whomever, and it's "just" your own time]
- jack9 13y ago
  > annnnd then the database technology changes, and your benchmark results of three years ago are now actively hosing you Why would you use the benchmarks based on a technology you don't use? Continuous Integration is another word for "everything is a technology, even code" so your benchmarks are re-run every build and there's no problem. PosgreSQL has efficient and DB-specific bitwise operations, but if you switch to MySQL they don't work at all.
- ibejoeb 13y ago
  >Unless you have really compelling reasons to get snuggly with a particular vendor's technology I'll never understand this mentality. You bought it, so why not use it? Even OSS databases have some very compelling features. Take advantage. Use the hell out of your tools. This is tantamount to saying "I'm using Go, but I can't use goroutines, because some day I might want to use Python instead." Don't want to get too attached to the technology, right? The only time I ever tried to go abstract is when I sold on-premises software that had to support multiple enterprise-size clients' vendor choices. You know what happened? It took forever, everyone was unhappy, and ultimately it turned into 2 vendor-specific versions and dropping the least popular 3rd. Life was better after that.

In practice, the answer is not always obvious. Benchmarking multiple queries / approaches is generally worthwhile if performance is important.

by soora 13y ago

In practice, the answer is not always obvious. Benchmarking multiple queries / approaches is generally worthwhile if performance is important.

kabdib 13y ago

... annnnd then the database technology changes, and your benchmark results of three years ago are now actively hosing you. Or you have to change databases but you can't because you embedded a lot of logic in your database layer that can't be easily ported (somewhere, a salesman for your current database product is crying tears of joy and shouting his cash-register shout, "Ka-ching! Customer lock-in! Ka-CHING baby!". Avoid these people). Unless you have really compelling reasons to get snuggly with a particular vendor's technology, be conservative. [This still applies if you're using a "free" database engine; you're just not paying MS or Oracle or whomever, and it's "just" your own time]

jack9 13y ago
> annnnd then the database technology changes, and your benchmark results of three years ago are now actively hosing you Why would you use the benchmarks based on a technology you don't use? Continuous Integration is another word for "everything is a technology, even code" so your benchmarks are re-run every build and there's no problem. PosgreSQL has efficient and DB-specific bitwise operations, but if you switch to MySQL they don't work at all.
ibejoeb 13y ago
>Unless you have really compelling reasons to get snuggly with a particular vendor's technology I'll never understand this mentality. You bought it, so why not use it? Even OSS databases have some very compelling features. Take advantage. Use the hell out of your tools. This is tantamount to saying "I'm using Go, but I can't use goroutines, because some day I might want to use Python instead." Don't want to get too attached to the technology, right? The only time I ever tried to go abstract is when I sold on-premises software that had to support multiple enterprise-size clients' vendor choices. You know what happened? It took forever, everyone was unhappy, and ultimately it turned into 2 vendor-specific versions and dropping the least popular 3rd. Life was better after that.