using has_many: primary_key when it isn't the primary_key in the database
I'm working on a codebase that uses rails
and the previous developers have created a few models in postgres
that are references to each other. However they use activerecord
's primary_key
field even though the database doesn't show that field as the primary_key
. Is there any benefit or disadvantage to this? Keep in mind there is an index on the 'fake' primary_key
field .
# models
class A < ActiveRecord:Base
has_many :bs, primary_key: :special_id
end
class B < ActiveRecord::Base
belongs_to :a, primary_key: :special_id, foreign_key: :special_id
end
Actual primary_key is id
on B
but schema includes id
and special_id
. Index exists on special_id
ruby-on-rails postgresql activerecord
add a comment |
I'm working on a codebase that uses rails
and the previous developers have created a few models in postgres
that are references to each other. However they use activerecord
's primary_key
field even though the database doesn't show that field as the primary_key
. Is there any benefit or disadvantage to this? Keep in mind there is an index on the 'fake' primary_key
field .
# models
class A < ActiveRecord:Base
has_many :bs, primary_key: :special_id
end
class B < ActiveRecord::Base
belongs_to :a, primary_key: :special_id, foreign_key: :special_id
end
Actual primary_key is id
on B
but schema includes id
and special_id
. Index exists on special_id
ruby-on-rails postgresql activerecord
add a comment |
I'm working on a codebase that uses rails
and the previous developers have created a few models in postgres
that are references to each other. However they use activerecord
's primary_key
field even though the database doesn't show that field as the primary_key
. Is there any benefit or disadvantage to this? Keep in mind there is an index on the 'fake' primary_key
field .
# models
class A < ActiveRecord:Base
has_many :bs, primary_key: :special_id
end
class B < ActiveRecord::Base
belongs_to :a, primary_key: :special_id, foreign_key: :special_id
end
Actual primary_key is id
on B
but schema includes id
and special_id
. Index exists on special_id
ruby-on-rails postgresql activerecord
I'm working on a codebase that uses rails
and the previous developers have created a few models in postgres
that are references to each other. However they use activerecord
's primary_key
field even though the database doesn't show that field as the primary_key
. Is there any benefit or disadvantage to this? Keep in mind there is an index on the 'fake' primary_key
field .
# models
class A < ActiveRecord:Base
has_many :bs, primary_key: :special_id
end
class B < ActiveRecord::Base
belongs_to :a, primary_key: :special_id, foreign_key: :special_id
end
Actual primary_key is id
on B
but schema includes id
and special_id
. Index exists on special_id
ruby-on-rails postgresql activerecord
ruby-on-rails postgresql activerecord
asked Jan 2 at 16:34
Terence ChowTerence Chow
3,935154794
3,935154794
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The benefit, in theory, is that it's more readable. In your case A.find(id).bs
would join the B
s that have a corresponding b_id
in your A
table, which may not be as intuitive as using another name, in this case special_id
.
From a performance standpoint it should make no noticeable difference, provided there are indexes on both the primary and foreign key columns. The has_many
method will ultimately result in a query, so the only computational cost is to swap out the column name in the query string that ActiveRecord
generates.
You could try benchmarking the queries with the various key declarations, but I'd be amazed if it added even a millisecond to the query time.
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%2f54009902%2fusing-has-many-primary-key-when-it-isnt-the-primary-key-in-the-database%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The benefit, in theory, is that it's more readable. In your case A.find(id).bs
would join the B
s that have a corresponding b_id
in your A
table, which may not be as intuitive as using another name, in this case special_id
.
From a performance standpoint it should make no noticeable difference, provided there are indexes on both the primary and foreign key columns. The has_many
method will ultimately result in a query, so the only computational cost is to swap out the column name in the query string that ActiveRecord
generates.
You could try benchmarking the queries with the various key declarations, but I'd be amazed if it added even a millisecond to the query time.
add a comment |
The benefit, in theory, is that it's more readable. In your case A.find(id).bs
would join the B
s that have a corresponding b_id
in your A
table, which may not be as intuitive as using another name, in this case special_id
.
From a performance standpoint it should make no noticeable difference, provided there are indexes on both the primary and foreign key columns. The has_many
method will ultimately result in a query, so the only computational cost is to swap out the column name in the query string that ActiveRecord
generates.
You could try benchmarking the queries with the various key declarations, but I'd be amazed if it added even a millisecond to the query time.
add a comment |
The benefit, in theory, is that it's more readable. In your case A.find(id).bs
would join the B
s that have a corresponding b_id
in your A
table, which may not be as intuitive as using another name, in this case special_id
.
From a performance standpoint it should make no noticeable difference, provided there are indexes on both the primary and foreign key columns. The has_many
method will ultimately result in a query, so the only computational cost is to swap out the column name in the query string that ActiveRecord
generates.
You could try benchmarking the queries with the various key declarations, but I'd be amazed if it added even a millisecond to the query time.
The benefit, in theory, is that it's more readable. In your case A.find(id).bs
would join the B
s that have a corresponding b_id
in your A
table, which may not be as intuitive as using another name, in this case special_id
.
From a performance standpoint it should make no noticeable difference, provided there are indexes on both the primary and foreign key columns. The has_many
method will ultimately result in a query, so the only computational cost is to swap out the column name in the query string that ActiveRecord
generates.
You could try benchmarking the queries with the various key declarations, but I'd be amazed if it added even a millisecond to the query time.
answered Jan 2 at 17:54
NM PennypackerNM Pennypacker
4,692112531
4,692112531
add a comment |
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%2f54009902%2fusing-has-many-primary-key-when-it-isnt-the-primary-key-in-the-database%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