Hi,
Not being an expert in RoR, I have a logical query. It is not a programming question.
Situation is :
I have a Book model and status of the book can be anything from NEW, OLD, VERY_OLD. It can be NEW, OLD both or it could be OLD and VERY_OLD both. What would you suggest to implement in such a case? I wanted to save user choice in database.
I can create new model for Book condition but I feel that there must be some other nice way to handle it. Is there?
[...]
I have a Book model and status of the book can be anything from NEW, OLD, VERY_OLD. It can be NEW, OLD both or it could be OLD and VERY_OLD both. What would you suggest to implement in such a case? I wanted to save user choice in database.
[...]
Have book_publised_time field, and according to that, define derived attributes on wheather the book is old, new, or very old. You don't have to save user choice, fetch the data, check for condition and according to that do your calculation.
Mrinmoy Das
Is there any other information associated with the status? If not there is no point having another model. Just have boolean fields for each status and set them as appropriate. Or if there is a specific set of valid combinations (old, very old, old+very old etc) then you could use an enum field with a value for each combination.
Colin
Hi,
Not being an expert in RoR, I have a logical query. It is not a programming question.
Situation is :
I have a Book model and status of the book can be anything from NEW, OLD, VERY_OLD. It can be NEW, OLD both or it could be OLD and VERY_OLD both. What would you suggest to implement in such a case? I wanted to save user choice in database.
I can create new model for Book condition but I feel that there must be some other nice way to handle it. Is there?
Is there any other information associated with the status? If not there is no point having another model. Just have boolean fields for each status and set them as appropriate. Or if there is a specific set of valid combinations (old, very old, old+very old etc) then you could use an enum field with a value for each combination.
Does a "Book" have many "Copies"? Are you looking to enter a Book once (as in Winnie-the-Pooh, Milne, A.A.) and then have a Copy in paperback, slightly foxed cover, sun-faded page edges, 6 out of 10?
I could definitely see an argument for not re-typing all of the bibliographic detail since it will be identical for different copies of the same book.
Walter
Hi,
Not being an expert in RoR, I have a logical query. It is not a programming question.
Situation is :
I have a Book model and status of the book can be anything from NEW, OLD, VERY_OLD. It can be NEW, OLD both or it could be OLD and VERY_OLD both. What would you suggest to implement in such a case? I wanted to save user choice in database.
I can create new model for Book condition but I feel that there must be some other nice way to handle it. Is there?
Is there any other information associated with the status? If not there is no point having another model. Just have boolean fields for each status and set them as appropriate. Or if there is a specific set of valid combinations (old, very old, old+very old etc) then you could use an enum field with a value for each combination.
Does a "Book" have many "Copies"? Are you looking to enter a Book once (as in Winnie-the-Pooh, Milne, A.A.) and then have a Copy in paperback, slightly foxed cover, sun-faded page edges, 6 out of 10?
Ah, that would make sense, I was having difficulty understanding how the same book could have multiple statuses.
Colin
I hate to go overboard on this question but I think a lot can be learned here.
Your question dives into several sub-topics at once (database normalization, model associations, and ERD structures). I would concentrate on the following first:
1. Use a good diagramming ERD software (RISE is a good free one)
This will help you create a visual diagram of your models and help you better define and establish relationships with them.
2. Database normalization.
It's important to keep your database normalized but there are instances where you can go too far and create a very unwieldy structure. Read up on normalization and get a solid grasp on it before you get too deep in your project.
3. Model Associations
Once you have done the above, I'd ask a few questions.
First, let's talk about books in general and what is common about them.
Books have titles (they can also have duplicate titles) Books have authors (single or multiple) Books have identification numbers Books have many editions Books can be hardback or paperback or electronic Books have value Books have conditions (age, wear, signed/unsigned, etc.)
Second, as far as looking at a book as a simple object, what pieces should really go in the book model? While that's solely up to you I would drive the following:
Book Model
has_many :conditions
title:string authors:text (you can serialize the field as JSON to store a hash) identification:string edition:string published_date:date hardback:boolean paperback:boolean
It would be difficult to use ISBN as an ident on every book since it has only been uniquely assigned since 1970.
Condition Model
belongs_to :book
book_id:integer age:integer signed:boolean torn:boolean pages_missing:boolean marked:boolean pristine:boolean
Even though books have a published date, the edition might change the age of the book.
I hope this example helps.
I could have used the Enums as well but I preferred to go with boolean fields.
I will have three boolean fields(OLD, NEW, VERY_OLD). As I wrote earlier, values could be multiple as well. So, If status is OLD and VERY_OLD both, then I will mark "is_old" & "is_very_old" columns as true/1.
Joel Dezenzio wrote in post #1173071:
I hate to go overboard on this question but I think a lot can be learned here.
Your question dives into several sub-topics at once (database normalization, model associations, and ERD structures). I would concentrate on the following first:
Even though books have a published date, the edition might change the age of the book.
I hope this example helps.
I have completely no idea where you are going with the question.. 
Sorry!
I think you told me much about the Rails structure in your answer but
did not answer my question.
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks