I have to jump in again. @lottemint.md please consider this mode of thinking, and let me know your opinion:
In your original post you have a data table: Pin
And an item called Details - which references an item in another table called PinDetails
Here’s what I think.
If you Do a search for Pins you will also load PinDetails
If you look in the developer console (like the screenshot you provided) you will likely see something like
PinDetails_custom_PinDetails: "1348695171700984260__LOOKUP__1588093645265x909152813332037600"
Which seems to me. That If you do a search for pins, you are also loading Pin details. Which in my opinion; may not have as much of a database advantage as what has been suggested here.
I agree 100% that we should set up different data tables. Its good practice for general app maintenance; and it also would optimize workflows in some instances (by removing “code”/load).
But I am still convinced, that if you Do a search for Pins you are also going to be loading PinsDetails (regardless of it hiding in a different data table)…
And @vladlarin - I agree Josh is probably the best resource on performance. In the link you have provided though: he says
The more data a search fetches, the longer it takes. That probably sounds pretty basic, but we routinely see pages that fetch thousands of data items on page load
I realize there is likely more depth and context here. But as a general principle; what Josh is saying here, kind of conflicts with the idea of a user in @lottemint.md pinterest example, searching through 10 million pins to find 5 saved pins…
So even if you Contraint the search, so tightly that the servers themselves are gasping for air. It still seems like a weirdly intensive query…
Sorry to continue this thread guys. But I have to admit I am not totally satisfied. I think some type of concrete answer, has yet to surface.
Do people at least understand what I am trying to say?