Rails models for Users, Offers, Comments, Documents, and Reviews
up vote
4
down vote
favorite
I want to simplify my Rails models, current looks like this:
class User < ActiveRecord::Base
has_many :offers, dependent: :destroy
has_many :reviews, dependent: :destroy
has_many :comments, dependent: :destroy
end
class Offer < ActiveRecord::Base
belongs_to :user
has_many :documents, as: :documentable
has_many :comments, dependent: :destroy
has_many :reviews, dependent: :destroy
end
class Review < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Comment < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Document < ActiveRecord::Base
belongs_to :documentable, polymorphic: true
end
As you can see, I have the same relations on Comment and Review models, but they have some difference in columns, what are the options do I have to minimize the amount of models?
ruby ruby-on-rails database active-record
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
asked Jan 25 '15 at 21:53
user2931706
212
add a comment |
up vote
4
down vote
favorite
I want to simplify my Rails models, current looks like this:
class User < ActiveRecord::Base
has_many :offers, dependent: :destroy
has_many :reviews, dependent: :destroy
has_many :comments, dependent: :destroy
end
class Offer < ActiveRecord::Base
belongs_to :user
has_many :documents, as: :documentable
has_many :comments, dependent: :destroy
has_many :reviews, dependent: :destroy
end
class Review < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Comment < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Document < ActiveRecord::Base
belongs_to :documentable, polymorphic: true
end
As you can see, I have the same relations on Comment and Review models, but they have some difference in columns, what are the options do I have to minimize the amount of models?
ruby ruby-on-rails database active-record
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
asked Jan 25 '15 at 21:53
user2931706
212
2
Why the desire for fewer models? If a review is different from a comment, then let them be different models. Maybe share some code via modules/concerns, but I see no reason to conflate the two just for the sake of "fewer models"
– Flambino
Jan 26 '15 at 1:44
@Flambino because I noticed duplication in Review and Comment models, and I was thinking that there's more elegant way of doing this
– user2931706
Jan 26 '15 at 2:14
1
I'd say the most elegant way is to model your domain as best you can. If that means more models, then more models it is. Functionality-wise those models can share code (e.g. modules/concerns); less code is a good thing, but fewer models isn't a goal in and of itself. As long as a comment is somehow not the same as a review, and vice-versa, don't try to make it one-size-fits-all. It's more likely to end up as one-size-fits-none. And should the two diverge more in functionality later, you'll want distinct models anyway.
– Flambino
Jan 26 '15 at 12:18
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I want to simplify my Rails models, current looks like this:
class User < ActiveRecord::Base
has_many :offers, dependent: :destroy
has_many :reviews, dependent: :destroy
has_many :comments, dependent: :destroy
end
class Offer < ActiveRecord::Base
belongs_to :user
has_many :documents, as: :documentable
has_many :comments, dependent: :destroy
has_many :reviews, dependent: :destroy
end
class Review < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Comment < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Document < ActiveRecord::Base
belongs_to :documentable, polymorphic: true
end
As you can see, I have the same relations on Comment and Review models, but they have some difference in columns, what are the options do I have to minimize the amount of models?
ruby ruby-on-rails database active-record
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
asked Jan 25 '15 at 21:53
user2931706
212
I want to simplify my Rails models, current looks like this:
class User < ActiveRecord::Base
has_many :offers, dependent: :destroy
has_many :reviews, dependent: :destroy
has_many :comments, dependent: :destroy
end
class Offer < ActiveRecord::Base
belongs_to :user
has_many :documents, as: :documentable
has_many :comments, dependent: :destroy
has_many :reviews, dependent: :destroy
end
class Review < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Comment < ActiveRecord::Base
belongs_to :user
belongs_to :offer
end
class Document < ActiveRecord::Base
belongs_to :documentable, polymorphic: true
end
As you can see, I have the same relations on Comment and Review models, but they have some difference in columns, what are the options do I have to minimize the amount of models?
ruby ruby-on-rails database active-record
ruby ruby-on-rails database active-record
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
asked Jan 25 '15 at 21:53
user2931706
212
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
asked Jan 25 '15 at 21:53
user2931706
212
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
edited Dec 24 '16 at 22:24
Jamal♦
30.2k11115226
30.2k11115226
asked Jan 25 '15 at 21:53
user2931706
212
asked Jan 25 '15 at 21:53
user2931706
212
asked Jan 25 '15 at 21:53
user2931706
212
212
2
Why the desire for fewer models? If a review is different from a comment, then let them be different models. Maybe share some code via modules/concerns, but I see no reason to conflate the two just for the sake of "fewer models"
– Flambino
Jan 26 '15 at 1:44
@Flambino because I noticed duplication in Review and Comment models, and I was thinking that there's more elegant way of doing this
– user2931706
Jan 26 '15 at 2:14
1
I'd say the most elegant way is to model your domain as best you can. If that means more models, then more models it is. Functionality-wise those models can share code (e.g. modules/concerns); less code is a good thing, but fewer models isn't a goal in and of itself. As long as a comment is somehow not the same as a review, and vice-versa, don't try to make it one-size-fits-all. It's more likely to end up as one-size-fits-none. And should the two diverge more in functionality later, you'll want distinct models anyway.
– Flambino
Jan 26 '15 at 12:18
add a comment |
2
Why the desire for fewer models? If a review is different from a comment, then let them be different models. Maybe share some code via modules/concerns, but I see no reason to conflate the two just for the sake of "fewer models"
– Flambino
Jan 26 '15 at 1:44
@Flambino because I noticed duplication in Review and Comment models, and I was thinking that there's more elegant way of doing this
– user2931706
Jan 26 '15 at 2:14
1
I'd say the most elegant way is to model your domain as best you can. If that means more models, then more models it is. Functionality-wise those models can share code (e.g. modules/concerns); less code is a good thing, but fewer models isn't a goal in and of itself. As long as a comment is somehow not the same as a review, and vice-versa, don't try to make it one-size-fits-all. It's more likely to end up as one-size-fits-none. And should the two diverge more in functionality later, you'll want distinct models anyway.
– Flambino
Jan 26 '15 at 12:18
2
2
Why the desire for fewer models? If a review is different from a comment, then let them be different models. Maybe share some code via modules/concerns, but I see no reason to conflate the two just for the sake of "fewer models"
– Flambino
Jan 26 '15 at 1:44
Why the desire for fewer models? If a review is different from a comment, then let them be different models. Maybe share some code via modules/concerns, but I see no reason to conflate the two just for the sake of "fewer models"
– Flambino
Jan 26 '15 at 1:44
@Flambino because I noticed duplication in Review and Comment models, and I was thinking that there's more elegant way of doing this
– user2931706
Jan 26 '15 at 2:14
@Flambino because I noticed duplication in Review and Comment models, and I was thinking that there's more elegant way of doing this
– user2931706
Jan 26 '15 at 2:14
1
1
I'd say the most elegant way is to model your domain as best you can. If that means more models, then more models it is. Functionality-wise those models can share code (e.g. modules/concerns); less code is a good thing, but fewer models isn't a goal in and of itself. As long as a comment is somehow not the same as a review, and vice-versa, don't try to make it one-size-fits-all. It's more likely to end up as one-size-fits-none. And should the two diverge more in functionality later, you'll want distinct models anyway.
– Flambino
Jan 26 '15 at 12:18
I'd say the most elegant way is to model your domain as best you can. If that means more models, then more models it is. Functionality-wise those models can share code (e.g. modules/concerns); less code is a good thing, but fewer models isn't a goal in and of itself. As long as a comment is somehow not the same as a review, and vice-versa, don't try to make it one-size-fits-all. It's more likely to end up as one-size-fits-none. And should the two diverge more in functionality later, you'll want distinct models anyway.
– Flambino
Jan 26 '15 at 12:18
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
First thing is if they are different treat them different. You can share code with help of interaction or service of some other way may be with active active_interaction. But if you really want to have less table then you may define one single model say Content and this will have a column content_type: integer with default value as 0 and all your other columns then convert the content_type to enum something like below
class Content < ApplicationRecord
enum content_type: { comment: 0, rating: 1 }
end
this will help you to differentiate between comment and rating. With proper indexing it will make no issue.
answered May 29 at 7:31
Manishh
1014
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
First thing is if they are different treat them different. You can share code with help of interaction or service of some other way may be with active active_interaction. But if you really want to have less table then you may define one single model say Content and this will have a column content_type: integer with default value as 0 and all your other columns then convert the content_type to enum something like below
class Content < ApplicationRecord
enum content_type: { comment: 0, rating: 1 }
end
this will help you to differentiate between comment and rating. With proper indexing it will make no issue.
answered May 29 at 7:31
Manishh
1014
add a comment |
up vote
0
down vote
First thing is if they are different treat them different. You can share code with help of interaction or service of some other way may be with active active_interaction. But if you really want to have less table then you may define one single model say Content and this will have a column content_type: integer with default value as 0 and all your other columns then convert the content_type to enum something like below
class Content < ApplicationRecord
enum content_type: { comment: 0, rating: 1 }
end
this will help you to differentiate between comment and rating. With proper indexing it will make no issue.
answered May 29 at 7:31
Manishh
1014
add a comment |
up vote
0
down vote
up vote
0
down vote
First thing is if they are different treat them different. You can share code with help of interaction or service of some other way may be with active active_interaction. But if you really want to have less table then you may define one single model say Content and this will have a column content_type: integer with default value as 0 and all your other columns then convert the content_type to enum something like below
class Content < ApplicationRecord
enum content_type: { comment: 0, rating: 1 }
end
this will help you to differentiate between comment and rating. With proper indexing it will make no issue.
answered May 29 at 7:31
Manishh
1014
First thing is if they are different treat them different. You can share code with help of interaction or service of some other way may be with active active_interaction. But if you really want to have less table then you may define one single model say Content and this will have a column content_type: integer with default value as 0 and all your other columns then convert the content_type to enum something like below
class Content < ApplicationRecord
enum content_type: { comment: 0, rating: 1 }
end
this will help you to differentiate between comment and rating. With proper indexing it will make no issue.
answered May 29 at 7:31
Manishh
1014
answered May 29 at 7:31
Manishh
1014
answered May 29 at 7:31
Manishh
1014
answered May 29 at 7:31
Manishh
1014
1014
add a comment |
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- 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.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2fcodereview.stackexchange.com%2fquestions%2f78573%2frails-models-for-users-offers-comments-documents-and-reviews%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
2
Why the desire for fewer models? If a review is different from a comment, then let them be different models. Maybe share some code via modules/concerns, but I see no reason to conflate the two just for the sake of "fewer models"
– Flambino
Jan 26 '15 at 1:44
@Flambino because I noticed duplication in Review and Comment models, and I was thinking that there's more elegant way of doing this
– user2931706
Jan 26 '15 at 2:14
1
I'd say the most elegant way is to model your domain as best you can. If that means more models, then more models it is. Functionality-wise those models can share code (e.g. modules/concerns); less code is a good thing, but fewer models isn't a goal in and of itself. As long as a comment is somehow not the same as a review, and vice-versa, don't try to make it one-size-fits-all. It's more likely to end up as one-size-fits-none. And should the two diverge more in functionality later, you'll want distinct models anyway.
– Flambino
Jan 26 '15 at 12:18