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;
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,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
|
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 |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%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.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
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,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
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