Timeline for When do you know that you've made a design flaw in a SQL/relational database?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 16, 2016 at 17:19 | history | tweeted | twitter.com/StackDBAs/status/732259104446681088 | ||
| May 12, 2016 at 19:39 | vote | accept | gr1zzly be4r | ||
| May 11, 2016 at 7:03 | answer | added | James K. Lowden | timeline score: 0 | |
| May 11, 2016 at 6:29 | comment | added | user1822 | 4 or 5 nested subqueries sound somewhat questionable. There might be better ways to deal with that (e.g. using common table expressions to avoid repeating sub-selects, window functions, lateral joins, ...). But that's impossible to answer without details. Joining 6 or 7 tables doesn't sound strange at all. While queries with 300 LoC are nothing uncommon I would expect them more frequently in reporting/DWH environment not in an OLTP environment. Again, without details this can't be judged. | |
| May 11, 2016 at 5:33 | answer | added | guest | timeline score: 4 | |
| May 3, 2016 at 18:19 | comment | added | ConstantineK | "Perfect" modeling and scaling can be at odds in some cases, lack of FKS might be a problem because some engines can optimize away some of the work, but at the end of the day the queries themselves are more likely to be the cause of your issue. Depending on your engine understanding "how" the execution works will probably drive better answers than "should I redesign" without context. | |
| May 3, 2016 at 18:17 | review | First posts | |||
| May 3, 2016 at 18:18 | |||||
| May 3, 2016 at 18:13 | history | asked | gr1zzly be4r | CC BY-SA 3.0 |