In my Rails project, I have the two similar models SafetyTest and TeamDue. Their fields are exactly the same, and they differ only in name. Each instance belongs_to a Student.
I would like to add the ability to create new models that follow the structure of the two above. So maybe I'd like to add MedicalForm. I don't want to do this over a CLI as a developer, but provide an interface in the view so that administrators can add their own.
Let's say that SafetyTest, TeamDue, and MedicalForm can all be described with the name SeasonalRequirement. What would be the best and most maintainable way to implement my idea?
I'm not experienced in Rails, but an idea that I had was to incorporate the models above into one comprehensive model called SeasonalRequirement, and just add a type column for every type. The problem with this: How would users create a new type of seasonal requirement (such as MedicalForm)? And how would I even determine what types of seasonal requirements there are when I'm trying to display a separate section for every one?
I would consider a polymorphic or STI relationship for this.
See more details at: http://code.alexreisner.com/articles/single-table-inheritance-in-rails.html
I would use STI to model this.
Not used RoR much, bu it seems like a bad idea to have the users change the structure of the database.
What might work is something like this:
additional_student_columns
--------------------------
id
name
and add another table:
additional_student_values
--------------------------
student_id
column_id
value (string)
The disadvantage of this is that it can use just string values
Related
I am trying to find the name of my problem:
A Comment table contains comments made by User on either a Concert or Play or Album or Painting, etc.
I am trying to avoid using many different comment tables CommentPlay, CommentAlbum!
This is perhaps a one-to-many relationship until I want to search for all Comments under a specific Play. There must be a comment_type (e.g. for_play, for_album) somewhere but I do not know how to include that in the relationship.
I am accessing the database using abstract SQL (Perl's DBIx::Class) and would like to remain db-vendor agnostic (among SQLite, MySQL, Pg).
Could someone give me a pointer as to what exactly is the name of the situation I am facing?
I have over 100 basic types in my project. Assume that all of them just contains an Id and a Title , so which of these approach is better to use :
Approach 1 : create a separate table for each of them
Approach 2 : Create a table for all of them and use another field as discriminator
I am using Using MSSQL server with Entity Framework Code-First Approach . Actually I can not decide which approach I should choose to use.
I think the question is self-briefed , but Let me know if you need more details.
UPDATE1 : Please do not refer me to this question . I have checked this one , wasnt that much helpful
UPDATE2 : Many of these tables have many relations to the other tables. but some of them wont use that much
100 types that inherits from Id/Title base type and EF TPH (so the DB will have 1 table with discriminator and programmers will have 100 types).
Approach1 will keep relation integrity and clean navigation properties form models.
Also your IDE will helps you completing rigth model names.
The tip: create and interface for all tables in order to reuse UI controls.
Edited
If you found a business name for this table, like customer_data then do a single table. If name is related with technology master_tables split into full semantical classes.
I'm creating a database of motorcycle and was wondering what the best way to go about setting it out is.
i would like to normalise the data as best as possible so save any headaches further down the line.
I anticipate having the following tables so far:
Manufacturer
ID,name,country,image
Model
ID,name,manufactureID,engine_size,power,torque,description,weight + various other specifications
I'll also want to separate models by type,so should I have a another table with the details below or should I just include this in the model table?
Type
ID,Sports,Supersports,Touring,Cruiser,Off-road
Similar to the type, I want to categorise motorcycle by licence type. Again should I create a separate licence table or just have it as a string in the model table.
I'll need front end users to be able to search the database based on type, licence, manufacture and model.
I'll need them to be able to sort by things like weight, power etc..
Is there a best practice approach to this?
Yes, you should create another table for TYPE and add a reference in Model table.
Yes, you should add licence type also.
To sort them by weight,power; you can do it just from your model table.
I'm brand new to Laravel and Eloquent (and I have minimal experience with ORM in general).
Let's say I have three database tables:
Widgets
Actions
Users
I have modelled one junction table that has columns for:
widget_id
action_id
user_id
timestamp
The point of the junction is to keep a log of interactions--take a timestamp every time a user performs an action on a widget. I see how to model a simple many-to-many relationship using Eloquent and have this working fine, but I'm not sure how to model a more complicated three-way relationship.
For that matter, even if I had a simply many-to-many relationship (say widget to action so there would be a table called action_widget), how can I add an explicit model for the action_widget table in Eloquent, for the purpose of keeping track of extra data about each relationship (e.g. a timestamp, a comments field, etc). Or, am I just going about this in a totally wrong way?
Being new to ORM, I feel very confined as to what I can do! Does this feeling go away? :p
pivot work fine when you have 2 way relation like Categoty<->Article.
but if you have 3 way relation i think it's better to have a model called WidgetUserAction.
Edit : For these cases the new "hasManyThrough" works fine.
Laravel can create the intermediate model automatically. They're called "pivot tables".
I suggest you read this section in the documentation.
when it comes down to increasing performance, reducing the amount of single SQL-Queries is one part of that.
Now let's assume a very basic example: i have a blog-table and a user-table. Each blog is referencing to a user by a given primary key.
A statement could be like
SELECT blog.title, blog.text, user.name FROM blog, user INNER JOIN on blog.user_id = user.id
Now my Blog-object i would like to have a $user-property which is a User-object
My Question: Are there inbuilt features within ZF2 to handle such a case? Or would i be needed to either manually map each field of the result into my objects?
Thanks in advance
No, there are no inbuilt features with ZF2 to do this - you should consider Doctrine 2 or Propel if you want that.
With Zend\Db however, you could write such SQL statements within your mapper class and then use an ArraySerializable hydrator to populate the blog entity. The blog entity's populate() could then choose to create a user object with the user data that is passed to it.