Is there a name for a filtering index for search
Is there a name for the pattern of creating a search index for filtering/sorting/paging then just having the your javascript request a list of ids (found in the index)?
Some back story:
I've got a pretty common requirement to create a list of products for filtering, sorting and paging.
My normal method of going about this is to have my back end create what I've self labeled an index, which is basically just a json list of objects with the id and filter/sort variables. I can pretty easily filter/sort/slice(page) the list to get what I want, then just ajax back to the server to get the full product information by id. It seems to work fine for lists where I have under a few thousand items (10k json payload), so I've never questioned it.
This seems like it's a pretty obvious solution but when describing it to my coworkers they seem genuinely surprised that I'm not passing my filter/sort/page parameters all the way back to the web server and then translating it and sending it over to a SQL server to execute some horrifically complex query.
Does the thing I've described have a name? I just internally call it an index but my google-fu is weak and I can't seem to find anyone online to back me up as not crazy for doing things this way. (Is this a terrible idea for reasons I've maybe not seen?)
javascript c#
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
add a comment |
Is there a name for the pattern of creating a search index for filtering/sorting/paging then just having the your javascript request a list of ids (found in the index)?
Some back story:
I've got a pretty common requirement to create a list of products for filtering, sorting and paging.
My normal method of going about this is to have my back end create what I've self labeled an index, which is basically just a json list of objects with the id and filter/sort variables. I can pretty easily filter/sort/slice(page) the list to get what I want, then just ajax back to the server to get the full product information by id. It seems to work fine for lists where I have under a few thousand items (10k json payload), so I've never questioned it.
This seems like it's a pretty obvious solution but when describing it to my coworkers they seem genuinely surprised that I'm not passing my filter/sort/page parameters all the way back to the web server and then translating it and sending it over to a SQL server to execute some horrifically complex query.
Does the thing I've described have a name? I just internally call it an index but my google-fu is weak and I can't seem to find anyone online to back me up as not crazy for doing things this way. (Is this a terrible idea for reasons I've maybe not seen?)
javascript c#
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
1
I think you'll generally see better performance by doing the data selection/filtering at the SQL level rather than the application. SQL tends to be pretty optimized to do that sort of thing. You can imagine how returning all data and then doing your filtering and sorting in the application would scale poorly.
– Nick
Jan 18 at 14:17
Also, any time you can avoid sending a request to the server, you should do that. It'll make for a better user experience and reduce bandwidth. In the method you're using, it seems like there's an additional request going on.
– Nick
Jan 18 at 14:23
@Nick It's the same number of requests. First request is a very simple and highly cached "select filter fields from table". The follow up requests are just GetByID queries that are also heavily cached. I find you get a lot more performance/reuse out of a cached GetByID request that's used from many places on a site than a highly optimized query with a half dozen parameters.
– WhiteleyJ
Jan 18 at 15:05
add a comment |
Is there a name for the pattern of creating a search index for filtering/sorting/paging then just having the your javascript request a list of ids (found in the index)?
Some back story:
I've got a pretty common requirement to create a list of products for filtering, sorting and paging.
My normal method of going about this is to have my back end create what I've self labeled an index, which is basically just a json list of objects with the id and filter/sort variables. I can pretty easily filter/sort/slice(page) the list to get what I want, then just ajax back to the server to get the full product information by id. It seems to work fine for lists where I have under a few thousand items (10k json payload), so I've never questioned it.
This seems like it's a pretty obvious solution but when describing it to my coworkers they seem genuinely surprised that I'm not passing my filter/sort/page parameters all the way back to the web server and then translating it and sending it over to a SQL server to execute some horrifically complex query.
Does the thing I've described have a name? I just internally call it an index but my google-fu is weak and I can't seem to find anyone online to back me up as not crazy for doing things this way. (Is this a terrible idea for reasons I've maybe not seen?)
javascript c#
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
Is there a name for the pattern of creating a search index for filtering/sorting/paging then just having the your javascript request a list of ids (found in the index)?
Some back story:
I've got a pretty common requirement to create a list of products for filtering, sorting and paging.
My normal method of going about this is to have my back end create what I've self labeled an index, which is basically just a json list of objects with the id and filter/sort variables. I can pretty easily filter/sort/slice(page) the list to get what I want, then just ajax back to the server to get the full product information by id. It seems to work fine for lists where I have under a few thousand items (10k json payload), so I've never questioned it.
This seems like it's a pretty obvious solution but when describing it to my coworkers they seem genuinely surprised that I'm not passing my filter/sort/page parameters all the way back to the web server and then translating it and sending it over to a SQL server to execute some horrifically complex query.
Does the thing I've described have a name? I just internally call it an index but my google-fu is weak and I can't seem to find anyone online to back me up as not crazy for doing things this way. (Is this a terrible idea for reasons I've maybe not seen?)
javascript c#
javascript c#
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
asked Jan 18 at 14:12
WhiteleyJWhiteleyJ
4831615
4831615
1
I think you'll generally see better performance by doing the data selection/filtering at the SQL level rather than the application. SQL tends to be pretty optimized to do that sort of thing. You can imagine how returning all data and then doing your filtering and sorting in the application would scale poorly.
– Nick
Jan 18 at 14:17
Also, any time you can avoid sending a request to the server, you should do that. It'll make for a better user experience and reduce bandwidth. In the method you're using, it seems like there's an additional request going on.
– Nick
Jan 18 at 14:23
@Nick It's the same number of requests. First request is a very simple and highly cached "select filter fields from table". The follow up requests are just GetByID queries that are also heavily cached. I find you get a lot more performance/reuse out of a cached GetByID request that's used from many places on a site than a highly optimized query with a half dozen parameters.
– WhiteleyJ
Jan 18 at 15:05
add a comment |
1
I think you'll generally see better performance by doing the data selection/filtering at the SQL level rather than the application. SQL tends to be pretty optimized to do that sort of thing. You can imagine how returning all data and then doing your filtering and sorting in the application would scale poorly.
– Nick
Jan 18 at 14:17
Also, any time you can avoid sending a request to the server, you should do that. It'll make for a better user experience and reduce bandwidth. In the method you're using, it seems like there's an additional request going on.
– Nick
Jan 18 at 14:23
@Nick It's the same number of requests. First request is a very simple and highly cached "select filter fields from table". The follow up requests are just GetByID queries that are also heavily cached. I find you get a lot more performance/reuse out of a cached GetByID request that's used from many places on a site than a highly optimized query with a half dozen parameters.
– WhiteleyJ
Jan 18 at 15:05
1
1
I think you'll generally see better performance by doing the data selection/filtering at the SQL level rather than the application. SQL tends to be pretty optimized to do that sort of thing. You can imagine how returning all data and then doing your filtering and sorting in the application would scale poorly.
– Nick
Jan 18 at 14:17
I think you'll generally see better performance by doing the data selection/filtering at the SQL level rather than the application. SQL tends to be pretty optimized to do that sort of thing. You can imagine how returning all data and then doing your filtering and sorting in the application would scale poorly.
– Nick
Jan 18 at 14:17
Also, any time you can avoid sending a request to the server, you should do that. It'll make for a better user experience and reduce bandwidth. In the method you're using, it seems like there's an additional request going on.
– Nick
Jan 18 at 14:23
Also, any time you can avoid sending a request to the server, you should do that. It'll make for a better user experience and reduce bandwidth. In the method you're using, it seems like there's an additional request going on.
– Nick
Jan 18 at 14:23
@Nick It's the same number of requests. First request is a very simple and highly cached "select filter fields from table". The follow up requests are just GetByID queries that are also heavily cached. I find you get a lot more performance/reuse out of a cached GetByID request that's used from many places on a site than a highly optimized query with a half dozen parameters.
– WhiteleyJ
Jan 18 at 15:05
@Nick It's the same number of requests. First request is a very simple and highly cached "select filter fields from table". The follow up requests are just GetByID queries that are also heavily cached. I find you get a lot more performance/reuse out of a cached GetByID request that's used from many places on a site than a highly optimized query with a half dozen parameters.
– WhiteleyJ
Jan 18 at 15:05
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54255750%2fis-there-a-name-for-a-filtering-index-for-search%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54255750%2fis-there-a-name-for-a-filtering-index-for-search%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I think you'll generally see better performance by doing the data selection/filtering at the SQL level rather than the application. SQL tends to be pretty optimized to do that sort of thing. You can imagine how returning all data and then doing your filtering and sorting in the application would scale poorly.
– Nick
Jan 18 at 14:17
Also, any time you can avoid sending a request to the server, you should do that. It'll make for a better user experience and reduce bandwidth. In the method you're using, it seems like there's an additional request going on.
– Nick
Jan 18 at 14:23
@Nick It's the same number of requests. First request is a very simple and highly cached "select filter fields from table". The follow up requests are just GetByID queries that are also heavily cached. I find you get a lot more performance/reuse out of a cached GetByID request that's used from many places on a site than a highly optimized query with a half dozen parameters.
– WhiteleyJ
Jan 18 at 15:05