Querying efficiently from an index table The Next CEO of Stack OverflowHow does database indexing work?Multiple Indexes vs Multi-Column IndexesDifferences between INDEX, PRIMARY, UNIQUE, FULLTEXT in MySQL?What do Clustered and Non clustered index actually mean?How to query MongoDB with “like”?How to import CSV file to MySQL tableHow to see indexes for a database or table in MySQL?mongodb: Multikey indexing structure?How do I drop a MongoDB database from the command line?Fill matrix of occurences from column/row arrays of indexes

My ex-girlfriend uses my Apple ID to login to her iPad, do I have to give her my Apple ID password to reset it?

Lucky Feat: How can "more than one creature spend a luck point to influence the outcome of a roll"?

Does the Idaho Potato Commission associate potato skins with healthy eating?

If Nick Fury and Coulson already knew about aliens (Kree and Skrull) why did they wait until Thor's appearance to start making weapons?

Traveling with my 5 year old daughter (as the father) without the mother from Germany to Mexico

Why don't programming languages automatically manage the synchronous/asynchronous problem?

Reshaping json / reparing json inside shell script (remove trailing comma)

What day is it again?

Is dried pee considered dirt?

Won the lottery - how do I keep the money?

Audio Conversion With ADS1243

Is a distribution that is normal, but highly skewed, considered Gaussian?

Help understanding this unsettling image of Titan, Epimetheus, and Saturn's rings?

Aggressive Under-Indexing and no data for missing index

How to set page number in right side in chapter title page?

Can you teleport closer to a creature you are Frightened of?

Is it ever safe to open a suspicious HTML file (e.g. email attachment)?

Would a completely good Muggle be able to use a wand?

Physiological effects of huge anime eyes

Do I need to write [sic] when including a quotation with a number less than 10 that isn't written out?

I dug holes for my pergola too wide

Is it okay to majorly distort historical facts while writing a fiction story?

How did Beeri the Hittite come up with naming his daughter Yehudit?

What happened in Rome, when the western empire "fell"?



Querying efficiently from an index table



The Next CEO of Stack OverflowHow does database indexing work?Multiple Indexes vs Multi-Column IndexesDifferences between INDEX, PRIMARY, UNIQUE, FULLTEXT in MySQL?What do Clustered and Non clustered index actually mean?How to query MongoDB with “like”?How to import CSV file to MySQL tableHow to see indexes for a database or table in MySQL?mongodb: Multikey indexing structure?How do I drop a MongoDB database from the command line?Fill matrix of occurences from column/row arrays of indexes










1















I have a MySQL table in which 1000s of posts are indexed as follows



enter image description here



First column contains the keyword, second, the number of occurrences and in the 3rd column there is an array in which each index contains an array of length 3 such that 1st index represents the id of the post, 2nd the number of occurrences in that post and 3rd index contains an array of line numbers in which the keyword is found.



Now I want to create a search engine where users can search for posts based on keywords. The most basic solution would be to fetch all the results for each keyword from a mysql query and then find all the common post ids using javascript (as I am using Node).



I know there must be ways for making this efficient. I think of using MongoDB, but I am unsure whether it will work.
And also I cannot use elastic search.










share|improve this question



















  • 1





    Why isn't this normalized?

    – Sergio Tulentsev
    Mar 8 at 17:28











  • I had the same reaction when I saw the db. But the indexing has been done by someone else and this is what finally I have.

    – Mayank Raj
    Mar 8 at 17:33











  • "I think of using MongoDB" - if changing the database (to something radically different) is an approach you're considering, then surely transforming this into a more queryable form in the same database is not off the table?

    – Sergio Tulentsev
    Mar 8 at 17:50







  • 1





    yes, yes, use python script and transform this into normalized form. It's not any different.

    – Sergio Tulentsev
    Mar 8 at 17:56






  • 1





    This is still somewhat denormalized, but should be much more queryable, yes.

    – Sergio Tulentsev
    Mar 8 at 18:07















1















I have a MySQL table in which 1000s of posts are indexed as follows



enter image description here



First column contains the keyword, second, the number of occurrences and in the 3rd column there is an array in which each index contains an array of length 3 such that 1st index represents the id of the post, 2nd the number of occurrences in that post and 3rd index contains an array of line numbers in which the keyword is found.



Now I want to create a search engine where users can search for posts based on keywords. The most basic solution would be to fetch all the results for each keyword from a mysql query and then find all the common post ids using javascript (as I am using Node).



I know there must be ways for making this efficient. I think of using MongoDB, but I am unsure whether it will work.
And also I cannot use elastic search.










share|improve this question



















  • 1





    Why isn't this normalized?

    – Sergio Tulentsev
    Mar 8 at 17:28











  • I had the same reaction when I saw the db. But the indexing has been done by someone else and this is what finally I have.

    – Mayank Raj
    Mar 8 at 17:33











  • "I think of using MongoDB" - if changing the database (to something radically different) is an approach you're considering, then surely transforming this into a more queryable form in the same database is not off the table?

    – Sergio Tulentsev
    Mar 8 at 17:50







  • 1





    yes, yes, use python script and transform this into normalized form. It's not any different.

    – Sergio Tulentsev
    Mar 8 at 17:56






  • 1





    This is still somewhat denormalized, but should be much more queryable, yes.

    – Sergio Tulentsev
    Mar 8 at 18:07













1












1








1








I have a MySQL table in which 1000s of posts are indexed as follows



enter image description here



First column contains the keyword, second, the number of occurrences and in the 3rd column there is an array in which each index contains an array of length 3 such that 1st index represents the id of the post, 2nd the number of occurrences in that post and 3rd index contains an array of line numbers in which the keyword is found.



Now I want to create a search engine where users can search for posts based on keywords. The most basic solution would be to fetch all the results for each keyword from a mysql query and then find all the common post ids using javascript (as I am using Node).



I know there must be ways for making this efficient. I think of using MongoDB, but I am unsure whether it will work.
And also I cannot use elastic search.










share|improve this question
















I have a MySQL table in which 1000s of posts are indexed as follows



enter image description here



First column contains the keyword, second, the number of occurrences and in the 3rd column there is an array in which each index contains an array of length 3 such that 1st index represents the id of the post, 2nd the number of occurrences in that post and 3rd index contains an array of line numbers in which the keyword is found.



Now I want to create a search engine where users can search for posts based on keywords. The most basic solution would be to fetch all the results for each keyword from a mysql query and then find all the common post ids using javascript (as I am using Node).



I know there must be ways for making this efficient. I think of using MongoDB, but I am unsure whether it will work.
And also I cannot use elastic search.







mysql node.js mongodb indexing






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 8 at 17:26









Seth McClaine

4,16812146




4,16812146










asked Mar 8 at 17:17









Mayank RajMayank Raj

382416




382416







  • 1





    Why isn't this normalized?

    – Sergio Tulentsev
    Mar 8 at 17:28











  • I had the same reaction when I saw the db. But the indexing has been done by someone else and this is what finally I have.

    – Mayank Raj
    Mar 8 at 17:33











  • "I think of using MongoDB" - if changing the database (to something radically different) is an approach you're considering, then surely transforming this into a more queryable form in the same database is not off the table?

    – Sergio Tulentsev
    Mar 8 at 17:50







  • 1





    yes, yes, use python script and transform this into normalized form. It's not any different.

    – Sergio Tulentsev
    Mar 8 at 17:56






  • 1





    This is still somewhat denormalized, but should be much more queryable, yes.

    – Sergio Tulentsev
    Mar 8 at 18:07












  • 1





    Why isn't this normalized?

    – Sergio Tulentsev
    Mar 8 at 17:28











  • I had the same reaction when I saw the db. But the indexing has been done by someone else and this is what finally I have.

    – Mayank Raj
    Mar 8 at 17:33











  • "I think of using MongoDB" - if changing the database (to something radically different) is an approach you're considering, then surely transforming this into a more queryable form in the same database is not off the table?

    – Sergio Tulentsev
    Mar 8 at 17:50







  • 1





    yes, yes, use python script and transform this into normalized form. It's not any different.

    – Sergio Tulentsev
    Mar 8 at 17:56






  • 1





    This is still somewhat denormalized, but should be much more queryable, yes.

    – Sergio Tulentsev
    Mar 8 at 18:07







1




1





Why isn't this normalized?

– Sergio Tulentsev
Mar 8 at 17:28





Why isn't this normalized?

– Sergio Tulentsev
Mar 8 at 17:28













I had the same reaction when I saw the db. But the indexing has been done by someone else and this is what finally I have.

– Mayank Raj
Mar 8 at 17:33





I had the same reaction when I saw the db. But the indexing has been done by someone else and this is what finally I have.

– Mayank Raj
Mar 8 at 17:33













"I think of using MongoDB" - if changing the database (to something radically different) is an approach you're considering, then surely transforming this into a more queryable form in the same database is not off the table?

– Sergio Tulentsev
Mar 8 at 17:50






"I think of using MongoDB" - if changing the database (to something radically different) is an approach you're considering, then surely transforming this into a more queryable form in the same database is not off the table?

– Sergio Tulentsev
Mar 8 at 17:50





1




1





yes, yes, use python script and transform this into normalized form. It's not any different.

– Sergio Tulentsev
Mar 8 at 17:56





yes, yes, use python script and transform this into normalized form. It's not any different.

– Sergio Tulentsev
Mar 8 at 17:56




1




1





This is still somewhat denormalized, but should be much more queryable, yes.

– Sergio Tulentsev
Mar 8 at 18:07





This is still somewhat denormalized, but should be much more queryable, yes.

– Sergio Tulentsev
Mar 8 at 18:07












2 Answers
2






active

oldest

votes


















1














For normalization, you'd probably want at least two tables.



One for just holding the keywords (and an easily and quickly referenced keyword_id value).



A second table for the "index", holding (keyword_id, post_id, line_number). The existence of fields holding counts becomes a bit redundant when simple "count" queries on this index table can yield the same results without needing to be kept synchronized with string data.



Then to find posts with your keywords, you can just do a query like this:



SELECT i.post_id, COUNT(DISTINCT i.keyword_id) AS keywordsUsed 
FROM keywords AS k
INNER JOIN keywords_index AS i ON k.keyword_id = i.keyword_id
WHERE k.keyword IN ( 'your', 'list', 'of', 'keywords')
GROUP BY i.post_id
ORDER BY keywordsUsed DESC
;


or this



SELECT post_id, COUNT(DISTINCT keyword_id) AS keywordsUsed 
FROM keywords_index
WHERE keyword_id IN (
SELECT keyword_id
FROM keywords
WHERE keyword IN ( 'your', 'list', 'of', 'keywords')
)
GROUP BY post_id
ORDER BY keywordsUsed DESC
;


Another thing worth keeping in mind is that while this table feels much bigger (lots more rows), it will probably take up much less actual space (and be faster to access because of it):



The string [[113, 1, [822]], [199, 1, [11592]],[267, 1, [5293 is a minimum of 50 bytes (assuming single byte character set), not counting length specifier for the string itself. Even removing the count values and associated commas and spaces only reduces the data by 9 bytes.



113, 822
199, 11592
267, 5293

is 24 bytes, assuming INT is used for the id values.






share|improve this answer

























  • Thanks. You made it absolutely clear.

    – Mayank Raj
    Mar 9 at 2:13











  • "The existence of fields holding counts becomes a bit redundant" - yeeeeah, that's until you need to sort by counts/popularity :) And sort quickly, that is.

    – Sergio Tulentsev
    Mar 10 at 23:31












  • @SergioTulentsev With appropriate indexing, calculating counts should be relatively quick anyway; packing the subcounts into that string field still would have been worse, and it's questionable if the unpacked count the original design had would have been useful since it might count five references in one post with the same weight as single distinct references in five posts. My suggested design allows for counting total overall references, distinct posts with references, and references within a post relatively quickly. If better performance was really needed, a summary table could be created.

    – Uueerdo
    Mar 11 at 16:32



















0














Select query should be something like this:



Select third column name from table name where first column name like %?%



so if you pass in agree you should get [[2,1,[673], [7,3,[303, 2863, 2866],[9,2,[...]]



This should return your array which you should be able to map() over



if you want the first index...



array.map((subArray) => subArray[0]); //returns an array of the first index


this would return [2,7,9]



If you are trying to get the third index and combine them you should be able to do a foreach() and concat()



let sample = [];
array.forEach((subArray) => sample = sample.concat(subArray););



This would return `[673, 303, 2863, 2866, ...]






share|improve this answer


















  • 1





    Thanks. But this is what I am doing right now. I was thinking of a more efficient solution.

    – Mayank Raj
    Mar 8 at 17:40






  • 1





    I think the only way to be more efficient is to alter your data structure.

    – Seth McClaine
    Mar 8 at 18:22






  • 1





    True. I'll have to normalize it, to make it efficient.

    – Mayank Raj
    Mar 8 at 18:25











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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55068010%2fquerying-efficiently-from-an-index-table%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














For normalization, you'd probably want at least two tables.



One for just holding the keywords (and an easily and quickly referenced keyword_id value).



A second table for the "index", holding (keyword_id, post_id, line_number). The existence of fields holding counts becomes a bit redundant when simple "count" queries on this index table can yield the same results without needing to be kept synchronized with string data.



Then to find posts with your keywords, you can just do a query like this:



SELECT i.post_id, COUNT(DISTINCT i.keyword_id) AS keywordsUsed 
FROM keywords AS k
INNER JOIN keywords_index AS i ON k.keyword_id = i.keyword_id
WHERE k.keyword IN ( 'your', 'list', 'of', 'keywords')
GROUP BY i.post_id
ORDER BY keywordsUsed DESC
;


or this



SELECT post_id, COUNT(DISTINCT keyword_id) AS keywordsUsed 
FROM keywords_index
WHERE keyword_id IN (
SELECT keyword_id
FROM keywords
WHERE keyword IN ( 'your', 'list', 'of', 'keywords')
)
GROUP BY post_id
ORDER BY keywordsUsed DESC
;


Another thing worth keeping in mind is that while this table feels much bigger (lots more rows), it will probably take up much less actual space (and be faster to access because of it):



The string [[113, 1, [822]], [199, 1, [11592]],[267, 1, [5293 is a minimum of 50 bytes (assuming single byte character set), not counting length specifier for the string itself. Even removing the count values and associated commas and spaces only reduces the data by 9 bytes.



113, 822
199, 11592
267, 5293

is 24 bytes, assuming INT is used for the id values.






share|improve this answer

























  • Thanks. You made it absolutely clear.

    – Mayank Raj
    Mar 9 at 2:13











  • "The existence of fields holding counts becomes a bit redundant" - yeeeeah, that's until you need to sort by counts/popularity :) And sort quickly, that is.

    – Sergio Tulentsev
    Mar 10 at 23:31












  • @SergioTulentsev With appropriate indexing, calculating counts should be relatively quick anyway; packing the subcounts into that string field still would have been worse, and it's questionable if the unpacked count the original design had would have been useful since it might count five references in one post with the same weight as single distinct references in five posts. My suggested design allows for counting total overall references, distinct posts with references, and references within a post relatively quickly. If better performance was really needed, a summary table could be created.

    – Uueerdo
    Mar 11 at 16:32
















1














For normalization, you'd probably want at least two tables.



One for just holding the keywords (and an easily and quickly referenced keyword_id value).



A second table for the "index", holding (keyword_id, post_id, line_number). The existence of fields holding counts becomes a bit redundant when simple "count" queries on this index table can yield the same results without needing to be kept synchronized with string data.



Then to find posts with your keywords, you can just do a query like this:



SELECT i.post_id, COUNT(DISTINCT i.keyword_id) AS keywordsUsed 
FROM keywords AS k
INNER JOIN keywords_index AS i ON k.keyword_id = i.keyword_id
WHERE k.keyword IN ( 'your', 'list', 'of', 'keywords')
GROUP BY i.post_id
ORDER BY keywordsUsed DESC
;


or this



SELECT post_id, COUNT(DISTINCT keyword_id) AS keywordsUsed 
FROM keywords_index
WHERE keyword_id IN (
SELECT keyword_id
FROM keywords
WHERE keyword IN ( 'your', 'list', 'of', 'keywords')
)
GROUP BY post_id
ORDER BY keywordsUsed DESC
;


Another thing worth keeping in mind is that while this table feels much bigger (lots more rows), it will probably take up much less actual space (and be faster to access because of it):



The string [[113, 1, [822]], [199, 1, [11592]],[267, 1, [5293 is a minimum of 50 bytes (assuming single byte character set), not counting length specifier for the string itself. Even removing the count values and associated commas and spaces only reduces the data by 9 bytes.



113, 822
199, 11592
267, 5293

is 24 bytes, assuming INT is used for the id values.






share|improve this answer

























  • Thanks. You made it absolutely clear.

    – Mayank Raj
    Mar 9 at 2:13











  • "The existence of fields holding counts becomes a bit redundant" - yeeeeah, that's until you need to sort by counts/popularity :) And sort quickly, that is.

    – Sergio Tulentsev
    Mar 10 at 23:31












  • @SergioTulentsev With appropriate indexing, calculating counts should be relatively quick anyway; packing the subcounts into that string field still would have been worse, and it's questionable if the unpacked count the original design had would have been useful since it might count five references in one post with the same weight as single distinct references in five posts. My suggested design allows for counting total overall references, distinct posts with references, and references within a post relatively quickly. If better performance was really needed, a summary table could be created.

    – Uueerdo
    Mar 11 at 16:32














1












1








1







For normalization, you'd probably want at least two tables.



One for just holding the keywords (and an easily and quickly referenced keyword_id value).



A second table for the "index", holding (keyword_id, post_id, line_number). The existence of fields holding counts becomes a bit redundant when simple "count" queries on this index table can yield the same results without needing to be kept synchronized with string data.



Then to find posts with your keywords, you can just do a query like this:



SELECT i.post_id, COUNT(DISTINCT i.keyword_id) AS keywordsUsed 
FROM keywords AS k
INNER JOIN keywords_index AS i ON k.keyword_id = i.keyword_id
WHERE k.keyword IN ( 'your', 'list', 'of', 'keywords')
GROUP BY i.post_id
ORDER BY keywordsUsed DESC
;


or this



SELECT post_id, COUNT(DISTINCT keyword_id) AS keywordsUsed 
FROM keywords_index
WHERE keyword_id IN (
SELECT keyword_id
FROM keywords
WHERE keyword IN ( 'your', 'list', 'of', 'keywords')
)
GROUP BY post_id
ORDER BY keywordsUsed DESC
;


Another thing worth keeping in mind is that while this table feels much bigger (lots more rows), it will probably take up much less actual space (and be faster to access because of it):



The string [[113, 1, [822]], [199, 1, [11592]],[267, 1, [5293 is a minimum of 50 bytes (assuming single byte character set), not counting length specifier for the string itself. Even removing the count values and associated commas and spaces only reduces the data by 9 bytes.



113, 822
199, 11592
267, 5293

is 24 bytes, assuming INT is used for the id values.






share|improve this answer















For normalization, you'd probably want at least two tables.



One for just holding the keywords (and an easily and quickly referenced keyword_id value).



A second table for the "index", holding (keyword_id, post_id, line_number). The existence of fields holding counts becomes a bit redundant when simple "count" queries on this index table can yield the same results without needing to be kept synchronized with string data.



Then to find posts with your keywords, you can just do a query like this:



SELECT i.post_id, COUNT(DISTINCT i.keyword_id) AS keywordsUsed 
FROM keywords AS k
INNER JOIN keywords_index AS i ON k.keyword_id = i.keyword_id
WHERE k.keyword IN ( 'your', 'list', 'of', 'keywords')
GROUP BY i.post_id
ORDER BY keywordsUsed DESC
;


or this



SELECT post_id, COUNT(DISTINCT keyword_id) AS keywordsUsed 
FROM keywords_index
WHERE keyword_id IN (
SELECT keyword_id
FROM keywords
WHERE keyword IN ( 'your', 'list', 'of', 'keywords')
)
GROUP BY post_id
ORDER BY keywordsUsed DESC
;


Another thing worth keeping in mind is that while this table feels much bigger (lots more rows), it will probably take up much less actual space (and be faster to access because of it):



The string [[113, 1, [822]], [199, 1, [11592]],[267, 1, [5293 is a minimum of 50 bytes (assuming single byte character set), not counting length specifier for the string itself. Even removing the count values and associated commas and spaces only reduces the data by 9 bytes.



113, 822
199, 11592
267, 5293

is 24 bytes, assuming INT is used for the id values.







share|improve this answer














share|improve this answer



share|improve this answer








edited Mar 8 at 20:22

























answered Mar 8 at 20:07









UueerdoUueerdo

12.3k1816




12.3k1816












  • Thanks. You made it absolutely clear.

    – Mayank Raj
    Mar 9 at 2:13











  • "The existence of fields holding counts becomes a bit redundant" - yeeeeah, that's until you need to sort by counts/popularity :) And sort quickly, that is.

    – Sergio Tulentsev
    Mar 10 at 23:31












  • @SergioTulentsev With appropriate indexing, calculating counts should be relatively quick anyway; packing the subcounts into that string field still would have been worse, and it's questionable if the unpacked count the original design had would have been useful since it might count five references in one post with the same weight as single distinct references in five posts. My suggested design allows for counting total overall references, distinct posts with references, and references within a post relatively quickly. If better performance was really needed, a summary table could be created.

    – Uueerdo
    Mar 11 at 16:32


















  • Thanks. You made it absolutely clear.

    – Mayank Raj
    Mar 9 at 2:13











  • "The existence of fields holding counts becomes a bit redundant" - yeeeeah, that's until you need to sort by counts/popularity :) And sort quickly, that is.

    – Sergio Tulentsev
    Mar 10 at 23:31












  • @SergioTulentsev With appropriate indexing, calculating counts should be relatively quick anyway; packing the subcounts into that string field still would have been worse, and it's questionable if the unpacked count the original design had would have been useful since it might count five references in one post with the same weight as single distinct references in five posts. My suggested design allows for counting total overall references, distinct posts with references, and references within a post relatively quickly. If better performance was really needed, a summary table could be created.

    – Uueerdo
    Mar 11 at 16:32

















Thanks. You made it absolutely clear.

– Mayank Raj
Mar 9 at 2:13





Thanks. You made it absolutely clear.

– Mayank Raj
Mar 9 at 2:13













"The existence of fields holding counts becomes a bit redundant" - yeeeeah, that's until you need to sort by counts/popularity :) And sort quickly, that is.

– Sergio Tulentsev
Mar 10 at 23:31






"The existence of fields holding counts becomes a bit redundant" - yeeeeah, that's until you need to sort by counts/popularity :) And sort quickly, that is.

– Sergio Tulentsev
Mar 10 at 23:31














@SergioTulentsev With appropriate indexing, calculating counts should be relatively quick anyway; packing the subcounts into that string field still would have been worse, and it's questionable if the unpacked count the original design had would have been useful since it might count five references in one post with the same weight as single distinct references in five posts. My suggested design allows for counting total overall references, distinct posts with references, and references within a post relatively quickly. If better performance was really needed, a summary table could be created.

– Uueerdo
Mar 11 at 16:32






@SergioTulentsev With appropriate indexing, calculating counts should be relatively quick anyway; packing the subcounts into that string field still would have been worse, and it's questionable if the unpacked count the original design had would have been useful since it might count five references in one post with the same weight as single distinct references in five posts. My suggested design allows for counting total overall references, distinct posts with references, and references within a post relatively quickly. If better performance was really needed, a summary table could be created.

– Uueerdo
Mar 11 at 16:32














0














Select query should be something like this:



Select third column name from table name where first column name like %?%



so if you pass in agree you should get [[2,1,[673], [7,3,[303, 2863, 2866],[9,2,[...]]



This should return your array which you should be able to map() over



if you want the first index...



array.map((subArray) => subArray[0]); //returns an array of the first index


this would return [2,7,9]



If you are trying to get the third index and combine them you should be able to do a foreach() and concat()



let sample = [];
array.forEach((subArray) => sample = sample.concat(subArray););



This would return `[673, 303, 2863, 2866, ...]






share|improve this answer


















  • 1





    Thanks. But this is what I am doing right now. I was thinking of a more efficient solution.

    – Mayank Raj
    Mar 8 at 17:40






  • 1





    I think the only way to be more efficient is to alter your data structure.

    – Seth McClaine
    Mar 8 at 18:22






  • 1





    True. I'll have to normalize it, to make it efficient.

    – Mayank Raj
    Mar 8 at 18:25















0














Select query should be something like this:



Select third column name from table name where first column name like %?%



so if you pass in agree you should get [[2,1,[673], [7,3,[303, 2863, 2866],[9,2,[...]]



This should return your array which you should be able to map() over



if you want the first index...



array.map((subArray) => subArray[0]); //returns an array of the first index


this would return [2,7,9]



If you are trying to get the third index and combine them you should be able to do a foreach() and concat()



let sample = [];
array.forEach((subArray) => sample = sample.concat(subArray););



This would return `[673, 303, 2863, 2866, ...]






share|improve this answer


















  • 1





    Thanks. But this is what I am doing right now. I was thinking of a more efficient solution.

    – Mayank Raj
    Mar 8 at 17:40






  • 1





    I think the only way to be more efficient is to alter your data structure.

    – Seth McClaine
    Mar 8 at 18:22






  • 1





    True. I'll have to normalize it, to make it efficient.

    – Mayank Raj
    Mar 8 at 18:25













0












0








0







Select query should be something like this:



Select third column name from table name where first column name like %?%



so if you pass in agree you should get [[2,1,[673], [7,3,[303, 2863, 2866],[9,2,[...]]



This should return your array which you should be able to map() over



if you want the first index...



array.map((subArray) => subArray[0]); //returns an array of the first index


this would return [2,7,9]



If you are trying to get the third index and combine them you should be able to do a foreach() and concat()



let sample = [];
array.forEach((subArray) => sample = sample.concat(subArray););



This would return `[673, 303, 2863, 2866, ...]






share|improve this answer













Select query should be something like this:



Select third column name from table name where first column name like %?%



so if you pass in agree you should get [[2,1,[673], [7,3,[303, 2863, 2866],[9,2,[...]]



This should return your array which you should be able to map() over



if you want the first index...



array.map((subArray) => subArray[0]); //returns an array of the first index


this would return [2,7,9]



If you are trying to get the third index and combine them you should be able to do a foreach() and concat()



let sample = [];
array.forEach((subArray) => sample = sample.concat(subArray););



This would return `[673, 303, 2863, 2866, ...]







share|improve this answer












share|improve this answer



share|improve this answer










answered Mar 8 at 17:36









Seth McClaineSeth McClaine

4,16812146




4,16812146







  • 1





    Thanks. But this is what I am doing right now. I was thinking of a more efficient solution.

    – Mayank Raj
    Mar 8 at 17:40






  • 1





    I think the only way to be more efficient is to alter your data structure.

    – Seth McClaine
    Mar 8 at 18:22






  • 1





    True. I'll have to normalize it, to make it efficient.

    – Mayank Raj
    Mar 8 at 18:25












  • 1





    Thanks. But this is what I am doing right now. I was thinking of a more efficient solution.

    – Mayank Raj
    Mar 8 at 17:40






  • 1





    I think the only way to be more efficient is to alter your data structure.

    – Seth McClaine
    Mar 8 at 18:22






  • 1





    True. I'll have to normalize it, to make it efficient.

    – Mayank Raj
    Mar 8 at 18:25







1




1





Thanks. But this is what I am doing right now. I was thinking of a more efficient solution.

– Mayank Raj
Mar 8 at 17:40





Thanks. But this is what I am doing right now. I was thinking of a more efficient solution.

– Mayank Raj
Mar 8 at 17:40




1




1





I think the only way to be more efficient is to alter your data structure.

– Seth McClaine
Mar 8 at 18:22





I think the only way to be more efficient is to alter your data structure.

– Seth McClaine
Mar 8 at 18:22




1




1





True. I'll have to normalize it, to make it efficient.

– Mayank Raj
Mar 8 at 18:25





True. I'll have to normalize it, to make it efficient.

– Mayank Raj
Mar 8 at 18:25

















draft saved

draft discarded
















































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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55068010%2fquerying-efficiently-from-an-index-table%23new-answer', 'question_page');

);

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







Popular posts from this blog

How to get text form Clipboard with JavaScript in Firefox 56?How to validate an email address in JavaScript?How do JavaScript closures work?How do I remove a property from a JavaScript object?How do you get a timestamp in JavaScript?How do I copy to the clipboard in JavaScript?How do I include a JavaScript file in another JavaScript file?Get the current URL with JavaScript?How to replace all occurrences of a string in JavaScriptHow to check whether a string contains a substring in JavaScript?How do I remove a particular element from an array in JavaScript?

Can't initialize raids on a new ASUS Prime B360M-A motherboard2019 Community Moderator ElectionSimilar to RAID config yet more like mirroring solution?Can't get motherboard serial numberWhy does the BIOS entry point start with a WBINVD instruction?UEFI performance Asus Maximus V Extreme

List of MPs elected to the English parliament in 1640 (April) Contents List of constituencies and members See also Notes References Navigation menueNational Archives – The Glynde Place ArchivesCobbett's Parliamentary history of England, from the Norman Conquest in 1066 to the year 1803'Aldermen in Parliament', The Aldermen of the City of London: Temp. Henry III – 1912onepage&q&f&#61, false 229