4 ms·
Not that I don't believe you, but I'm genuinely curious. When you're designing a "beautiful relational database" without thinking about the algorithms behind i
by tonyarkles 15y ago
Not that I don't believe you, but I'm genuinely curious.
When you're designing a "beautiful relational database" without thinking about the algorithms behind it, how are you taking the performance effects of those algorithms into account? How do you know which relationships and queries are likely to be efficient and which are not?
- kenrikm 15y agoWhat I was trying to get across is that knowing the correct term for something and actually knowing how to do it are two different things. I run across stuff all the time in CS where I'm like huh? what's that? then I google it and find out "oh so that's what you call the way that I did "X" in "Y" application.
- Drbble 15y agoParent is talking about beautiful schema, not a beautiful query planner. If you are capable of understanding the concept of abstraction and encapsulation, you can design a good system knowing the performance characteristics of your components but not their internals. The geniuses who wrote postgres don't know how to write responsive web sites. The geniuses who make gorgeous fast websites don't know how a Btree is implemented. It's OK. That's how the global economy works.
- xsmasher 15y agoBut the fast-website people still need to know what makes a query slow and how to improve it. They don't (and shouldn't) write their own database engine, but they need to know how their equipment works.
- tonyarkles 15y agoThat's what I'm getting at though; a schema that is "beautiful" but performs terribly isn't all that beautiful in my eyes.