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

Thal And Out Agency railway station See also References External links Navigation menuOfficial Web Site of Pakistan RailwaysArchivedOfficial Web Site of Pakistan Railwayseeexpanding ite

Understanding generators in Python2019 Community Moderator ElectionGenerator function not working pythonFor loop not executing two timesGenerators - Printing generated valuesWhy can a python generator only be used once?What exactly do generators do?What does the “yield” keyword do?What does “list comprehension” mean? How does it work and how can I use it?sklearn Kfold acces single fold instead of for loopIs a generator the callable? Which is the generator?Apply Border To Range Of Cells Using OpenpyxlCalling an external command in PythonWhat are metaclasses in Python?What is the difference between @staticmethod and @classmethod?Finding the index of an item given a list containing it in PythonDifference between append vs. extend list methods in PythonHow can I safely create a nested directory in Python?Does Python have a ternary conditional operator?Understanding slice notationUnderstanding Python super() with __init__() methodsDoes Python have a string 'contains' substring method?

How can I change the color of pagination dots of UIPageControl?How to change UIPageControl dotsIs there a way to change page indicator dots colorCustomize dot with image of UIPageControl at index 0 of UIPageControlNo visible @interface for 'NSObject<PageControlDelegate>' declares the selector 'pageControlPageDidChange:'How to change the color of pagination dots in UIPageControl with a different color per pagepagecontrol indicator custom image instead of DefaultChanging the colour of UIPageControl dots in MonoTouchpagecontrol selectable page visibility color?Alternative way to load ViewControllers on a UIPageControlHow to set only layer.border-color for UIpage control dots in swiftHow can I develop for iPhone using a Windows development machine?How to change the name of an iOS app?UITableView - change section header coloruipagecontrol indicator(dot)issueCustom UIPageControl dots color not changingchange the interspace between UIPageControl dotsHow to change Status Bar text color in iOSHow can I change image tintColor in iOS and WatchKitUIPageControl dots with larger space in between each dotsHow to change the color of pagination dots in UIPageControl with a different color per page