Timeline for When does it make sense to duplicate data for querying
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 8, 2017 at 17:02 | vote | accept | gilmishal | ||
| Jan 8, 2017 at 16:54 | answer | added | Joel Brown | timeline score: 4 | |
| Jan 8, 2017 at 16:35 | answer | added | Aaron Bertrand | timeline score: 5 | |
| Jan 8, 2017 at 15:14 | comment | added | Aaron Bertrand | Why don't you design the system the way it makes logical sense, and deal with problematic joins when they prove to cause performance issues? Don't prematurely optimize just because you think joins are costly. Joins that are performance problems are usually because the queries are horrible (which could be requirements or bad query logic), there are missing indexes, or both. | |
| Jan 8, 2017 at 14:57 | comment | added | Erik Reasonable Rates Darling | How much overhead does it create to replicate the data? What's the overhead of queries to get the same results from it? How much tuning of your current queries and indexes have you done? | |
| Jan 8, 2017 at 14:05 | comment | added | gilmishal | When you put it that way it makes me feel silly, but I think joins are costly. The more tables you query the more overhead it creates. I think some times a certain db design is built for a quick query of one sort (in my case, being able to do relevant backend actions based on events) and does not fit for other sort of query - showing users their events. | |
| Jan 8, 2017 at 14:00 | comment | added | Aaron Bertrand | Joins are kind of an integral part of a relational database (a join is just a way to return data that represents the relation part of relational). Why do you think avoiding joins is a goal? | |
| Jan 8, 2017 at 13:41 | history | asked | gilmishal | CC BY-SA 3.0 |