Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I currently have three models: Business, Charity, and Organization. A business and charity are both types of organizations because they share many similar attributes (e.g. address, hours, website, etc.) however they each have their own unique attributes. How should I best handle the creation of the models in Active Record? Use STI or Polymorphism? Or should I break out each one into their own model with duplicate information and get rid of the Organization model?
You can use both, so it is not necessarily an either/or situation. Most importantly, however, is how you will structure your tables and the logic surrounding them, which depends on how you are going to query the data, and how these elements relate to one another.
There is not enough information above to give you very clear direction on what to use. However, if after reading:
Rails Guides
How and When to Use STI
... the solution isn't clear, here are some simple rules:
if the types of objects you are using mostly have the same attributes but have different business logic attached to them (ie, the behavior written into their Model classes), then STI is a good baseline idea, but
if they have the same logic as well, it may make sense just to create them as a single class with a "type" flag (but not the attribute type, since it is only for STI)
As far as polymorphism goes, it seems like these Models are all very similar and interchangeable -- polymorphism is more useful for relating unlike things (such as comments and photos) to another Model (such as a FB post). In that case, using either a single table or STI and relating based on the parent table may make more sense.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am creating an invoice application. Does the following flow diagram is the proper & complete application?
Am I missing any model?
Is there any other better way to design?
Is there any option to reduce the number of tables?
In the current model, when a user adds new invoice - I need to interact with almost all the tables.
When a user edits the same invoice - Again I need to interact with all the mentioned tables.
Well it's hard to say, because only you know the specification of your application and what it should do and you are posting some concept not a design (eg. UML diagrams). But giving the information you provide:
Invoice have one contact. Would be better having issuer and contractor (two contacts) in case you want to issue an invoice from many clients.
I can answer that question when I see UML diagrams.
Why you want to reduce a number of tables? If you want to you can have one big table but that's not the point. Just keep your database desing normalized (3rd normal form) and don't care about number of tables.
On a must, I think you don't need tax and currency relations, you can move them to Invoice attributes - but once again, I don't have the whole picture.
No, you don't. When you issue a new invoice to the same customer and sell him the same items you just add records to two tables (invoices, invoice items). Anyway don't think about modyfing the database that way, you have the DB to work on it :)
As mentioned above - no.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Excuse my lack of knowledge,
Lately, I am learning rails and found it extremely easy and fun, but still there is alot to learn.
I made an application for managing a Car workshop:
Owners has many cars
cars has many visits
visits belong to a car and an owner.
I wanna have the ability for diffrent users of workshops to manage their businesses, what is the currect design in order to make visits and cars and owners belong to that specific user, is making all models belong to User enough? where can I read about this? managing access to dabases based on the logged in user?
I read about authentication, but its not answering my question, which is the best design for my needs, which is workshops managing only their data.
You could probably check Devise (https://github.com/plataformatec/devise) which is one of the most common ways of handling authentication
In the end, you will have a User model and then you can treat it as any other model, so for example if you only want to show a user's cars you could do something like current_user.cars and restrict certain controller actions to happen only if user_signed_in? and so on. I do recommend checking their documentation, since most use cases are explained easily.
Devise can be used to handle authentication and Pundit or CanCanCan can be used for authorization. I'd recommend looking at those, there are many tutorials which will answer your question for those.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm curious if there is a preferred method for storing assets in a database, that is, the path to the files (I'll be using postgres if that matters). I'll have PDFs, Videos, and audio files.
Should I create a single table and have a 'type' field, or does it make more sense to create a pdfs table, videos table and audio table?
Thanks
This is a pretty common question when it comes to designing database, and there's no one-size-fits-all answer. It really depends on which of the two setups is going to be most useful to you. Or, which setup is going to cause you the least problems.
Logically, do you expect to deal with each resource differently? Or do you expect to treat them largely as subtle variants of the same type of thing? For example, are there relations or constraints in your data model which refer to one specific type (e.g. resumes.pdf_file_id would be specifically for a PDF file, and having it potentially be an mp3 wouldn't be very helpful). If yes, I'd go with separate tables.
On the other hand, if you want to be able to see all the attachments a user has uploaded, it would be easiest to just query a single table, e.g. SELECT * FROM attachments WHERE user_id=?, instead of dealing with selecting from three separate tables.
There are middle-ground options, though. You could have the separate tables, but link them all to an attachments table which stores the S3 URL. Or you could use database-level inheritance to treat them as both separate and unified tables (this solution often seems perfect, but I wouldn't recommend it). Ultimately, the best choice depends on your use case.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm developing app that help people overview results of their training. In different disciplines different calculations. And I need to store discipline in object related to training.
I have to use this values in code to programmaticaly set fields of another objects, calculate results depend on it, and later to compare with it.
For example I have model Discipline and three records with names
Speed on 400 m
Speed on 1 km
Speed on 4 km
So it's some kind of constants and I'm just wondering what is the best practice to declare and access them?
Or may be is there any way to declare predefined objects?
Anytime you have "predefined" objects you should probably look into using an enum, though I don't really know why you would want to do that with an AR model. The whole idea behind an AR model is that it's an interactive object backed by a database that can have its attributes manipulated via CRUD operations.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
What advantages and disadvantages do you know of Ruby on Rails polymorphic relationships.
Advantages:
You can link anything to anything quite easily
Adaptable relationships help accommodating unforeseen circumstances
Very easy to implement relationships
Great for ad-hoc systems
Disadvantages:
Foreign keys not practical
Indexes include another dimension of complexity
Relationships between tables hard to identify when using STI
Database diagramming tools cannot interpret
Not always practical for join models
Strongly discouraged for systems where data integrity must be verified
I'm a big fan of using relationships of this sort for records that are attached to a large number of things as required, for example, a comment or annotation record which may apply to a wide variety of records.
It is not very well suited for situations where the relationship is exercised in a JOIN frequently. That is, the polymorphic association should not be in the middle of a relationship between records, but as something on the perimeter.