Querying efficiently from an index table Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Data science time! April 2019 and salary with experience Should we burninate the [wrap] tag? The Ask Question Wizard is Live!How 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

Fundamental Solution of the Pell Equation

Identify plant with long narrow paired leaves and reddish stems

Using et al. for a last / senior author rather than for a first author

Why did the rest of the Eastern Bloc not invade Yugoslavia?

Why do people hide their license plates in the EU?

At the end of Thor: Ragnarok why don't the Asgardians turn and head for the Bifrost as per their original plan?

What is a non-alternating simple group with big order, but relatively few conjugacy classes?

Seeking colloquialism for “just because”

Is the Standard Deduction better than Itemized when both are the same amount?

Are two submodules (where one is contained in the other) isomorphic if their quotientmodules are isomorphic?

When do you get frequent flier miles - when you buy, or when you fly?

List *all* the tuples!

Single word antonym of "flightless"

What to do with chalk when deepwater soloing?

Apollo command module space walk?

How to tell that you are a giant?

Can an alien society believe that their star system is the universe?

String `!23` is replaced with `docker` in command line

How to find all the available tools in macOS terminal?

How to react to hostile behavior from a senior developer?

Why do we bend a book to keep it straight?

Using audio cues to encourage good posture

Overriding an object in memory with placement new

Can I cast Passwall to drop an enemy into a 20-foot pit?



Querying efficiently from an index table



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
Data science time! April 2019 and salary with experience
Should we burninate the [wrap] tag?
The Ask Question Wizard is Live!How 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



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








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,21912146




4,21912146










asked Mar 8 at 17:17









Mayank RajMayank Raj

382516




382516







  • 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.4k1816




12.4k1816












  • 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,21912146




4,21912146







  • 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

AWS Lex not identifying response if by a variable The 2019 Stack Overflow Developer Survey Results Are In Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) The Ask Question Wizard is Live! Data science time! April 2019 and salary with experienceEnforcing custom enumeration in AWS LEX for slot valuesHow to give response based on user response in Amazon Lex?Intercepting AWS Lambda Response to a AWS Lex QueryLex chat bot error: Reached second execution of fulfillment lambda on the same utteranceamazon lex showing invalid responseLambda response send back to Lex slot?Response card in Amazon lexAmazon Lex - Lambda response return HTML to botHow can I solve 424 (Failed Dependency) (python) obtained from Amazon lex?

Алба-Юлія

Захаров Федір Захарович