Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question: Shall adding foreign key constraint in access_tokens table for user_id column be an additional overhead #14

Closed
SamarRizvi opened this issue Jun 9, 2017 · 1 comment

Comments

@SamarRizvi
Copy link

If foreign key constraint for user_id is added in access_tokens table, shall it be an additional overhead when there are large number of users. I am asking this because, when I add foreign key constraint to user_id field, the index on it is removed, and indexing is for sure, good when there are large number of users. Or is it that adding a foreign key constraint to a column is automatically indexed.

So what to use, foreign key constraint or index for user_id?

@SamarRizvi SamarRizvi changed the title Question: Shall adding foreign key constraint in 'access_tokens' table be an additional overhead Question: Shall adding foreign key constraint in access_tokens for user_id column table be an additional overhead Jun 9, 2017
@SamarRizvi SamarRizvi changed the title Question: Shall adding foreign key constraint in access_tokens for user_id column table be an additional overhead Question: Shall adding foreign key constraint in access_tokens table for user_id column be an additional overhead Jun 9, 2017
@kot13
Copy link
Owner

kot13 commented Jun 24, 2017

Is there a search in access_token table by user_id?
It seems no. Therefore, I think that the index is not needed.

But foreign key constraint for user_id also increases overhead. Maybe it is not necessary?

For maximum performance, you should use key-value storage (Redis for example).

@kot13 kot13 closed this as completed Feb 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants