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 have a little system with some users.
An user with admin-rights can create a new lecture.
Thats already working.
Now i want to solve the problem that users can sign up to lectures.
So i want to add a new column (boolean type) e.g. to lecture1 in my users database when i create a new lecture. So i can set the variable to true if an user sign up.
Is that a good idea or would it be better to have a database (e.g. signupstatus) with an exercise_id, an user_id. When there is an entry the user has already sign up to the lecture.
Or does anyone have an better idea?
Thanks :)
The table is always better. You will never want to create such columns(lecture1...) in User table, for each new lecture which to added in your system. Imagine the series of such columns [lecture1,lecture2,lecture3,lecturen...] => Totally unconventional and against the design principles.
What you want is a simple Many-to-Many relationship. A Lecture can be enrolled by many users; a User can subscribe to many lectures.
You should follow this guide to achieve it.
This will create a table - lectures_users and store lecture_id and user_id to maintain the relationship
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 2 years ago.
Improve this question
I'm working on a rails app to teach myself associations. Its an app with Tutors and Students where Tutors create Students as Users and can then Tutors create "posts" for what was taught in that lesson to the specific Students page to show their progress. When the Student logs in they can only see their assigned progress and do nothing else.
I figured an option is having Students as "categories" so the Students can be filtered but what is the best practice?
It seems simple but I keep overthinking it
Generally you want to create the associations as you need them in your code later. So if a tutor has many students and many posts and a student has many posts and belongs to a tutor and so on.
In order to restrict it in the view, you can restrict that in the controller. So this is where you can filter the posts by the students then. So you could do student.posts (Beware, I am not super sure what your db structure/schema looks like).
And there are gems that handle authorization. Look at pundit (my favorite) or cancancan. With those you can specifiy for each controller action, who can see/do certain things.
Now judging from the little information you gave, you might also want to look into namespaced controllers because you probably have a posts#index for tutors and another one for students. Here you can get another layer of organisation by adding a so called namespace meaning you can have one posts controller under tutors and one under students. You can find more info here: https://guides.rubyonrails.org/routing.html#controller-namespaces-and-routing
Let me know if anything is unclear!
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 8 years ago.
Improve this question
My application is one page contract. I would like users to be able to sign the contract by clicking on a button. The contract is not a resource; it's plain HTML.
Every solution I have found so far relies on having a model that acts as votable. How can I implement a simple button that users may only click once, and display the number of users who have clicked it?
It's not possible to do this with static pages, at least not in a way that is clean and secure.
Think about it this way: every user is looking at a copy of the contract, which is being displayed to them on their browser (the client). If you want users to be able to cast votes that persist and be aware of votes cast by other users, then you need a server that keeps track of it centrally. That's why the solutions you have found so far rely on having a model, presumably backed with a table.
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
Friends i have controller with the name of shops and i have did likes and unlike option against a post.Now i want to make a third option for dislike.The purpose is that i want to show down voting.I am using rails 4 version and here below my code.Kindly help me as i dont know how to figure out my problem.
I think it would be better to start from scratch with a common Voting model. In your code above you have written only a controller and a view, but you need also a model.
Basically you need a Vote model and a controller with like, dislike and get_vote methods.
And don't forget to join the votes, users and voteable items.
For a hint how you could implement this, you can also see here: "Like", "Dislike" plugin for rails
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 9 years ago.
Improve this question
I was wondering how to implement a relationship with an attribute using CoreData. XCode 5 with iOS 7.
In my ER model I've got a relationship "participation" with the attribute "confirmed".
In this case I'd like to know whether participation in an event of a specific profile has been confirmed.
In SQL the table for this relation would look like this:
Participation (EventID, ProfileID, confirmed)
Unfortunately I can't post images due to lack of reputation.
Thanks in advance!
Nelson
You can create a new entity (Participation) which has 2 relationships (one to the Event and one to the Profile) and 1 attribute (your BOOL).
It isn't clear whether you already have this or not, but it can be used (by creating an instance of the entity) to connect your selected objects and hold the confirmed status.