Skip to main content
10 events
when toggle format what by license comment
Feb 12, 2020 at 5:57 vote accept Jahirul Islam
Jan 15, 2020 at 22:25 answer added Christophe timeline score: 1
Dec 20, 2019 at 14:16 comment added Berin Loritsch If you are joining with fairly static records, then you can have some performance savings by caching the static records and looking them up on the fly. Otherwise, test first, and if your stitching logic starts getting out of hand, abandon that approach.
Dec 20, 2019 at 12:30 comment added Jahirul Islam @Berin The result size would not exceed hundreds. But this process may need to be done moderately frequently. I plan on doing some testing to get solid numbers. But I wanted to get outside opinion on design decision
Dec 19, 2019 at 11:07 comment added Did Berin has good perspective on this I like it, also you should keep in mind that if you do get the data separately you may need to combine, compare, filter, etc which will create a lot of work for you because you need to handle that which in the other case just writing one query will give you the results you need. In my opinion, the Single Query Approach sounds better.
Dec 18, 2019 at 20:53 comment added imel96 Do the simpler first, your can refactor later when new requirements come
Dec 18, 2019 at 20:47 comment added Erik Eidt Send the query to the database, not the data to the app.
Dec 18, 2019 at 20:15 comment added Berin Loritsch Questions: do you have performance criteria? What's the result set size for data you have to manually join? do you have memory requirements? When you start looking at all the criteria, you start to settle in to a design that you need. You'll find that databases are really good at fairly complex queries and once you hit a certain threshold (to be determined by testing) the process of joining in a back end service becomes a major bottleneck.
Dec 18, 2019 at 19:10 review First posts
Dec 18, 2019 at 22:19
Dec 18, 2019 at 19:06 history asked Jahirul Islam CC BY-SA 4.0