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
I have a MySQL table in which 1000s of posts are indexed as follows

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
|
show 4 more comments
I have a MySQL table in which 1000s of posts are indexed as follows

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
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
|
show 4 more comments
I have a MySQL table in which 1000s of posts are indexed as follows

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
I have a MySQL table in which 1000s of posts are indexed as follows

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
mysql node.js mongodb indexing
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
|
show 4 more comments
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
|
show 4 more comments
2 Answers
2
active
oldest
votes
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.
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
add a comment |
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, ...]
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
add a comment |
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%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
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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, ...]
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
add a comment |
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, ...]
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
add a comment |
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, ...]
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, ...]
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
add a comment |
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
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55068010%2fquerying-efficiently-from-an-index-table%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown

1
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