I'm trying to get used to relational active record but things look too complicated for now.
If it's not difficult please point me in right direction.
I have 4 tables.
Users
userID[pk],userName
Cars
car_id[pk],userID[fk to Users],car_nickname,make_id[fk to Makes],model_id[fk to Models]
Makes
make_id[pk],make_name
Models
model_id[pk],model_name,make_id[fk to Makes]
Now input data is userName,make_name,model_name and task is to get car_nickname from Cars table.
Is this possible using relations or should I do it step by step checking makes,models,users for IDs and then puting all IDs into Cars to get car_nickname ?
You can yous only one Model with reliations to all tables. And create one _form.php in the Views, where there will only fields you need.
Some halpfull information. if you save some data into some table and you need saved data id, you caN use $newid = $model->getPrimaryKey(); and assign to new variable , wich will save into other tables.
I think this is short way to solve problem
Related
Heya I am novice web dev or actually I am still in education.
I got this situation Where I have 3 tables lets say : Students, Groups and a join table Student_group.
I put my data from Students in the student model and from groups I put its data in the Group Model so I can use it my application. But I store a date in the Student_group table because I need to know when a student changed from a group.
So my question is in which model do I put this date? Do i need to make a new model for the combined tables or do I need to add another attribute to the student model?
Thanks in advance ;D
That depends. Will the student be in many groups, or one?
If one (one to one relationship), you can decide where to put it. The column could be in either the Student table, or the Student_group. In this case, though, it may be advisable to flatten the data and simply add group columns in your Student table. You decide that as well - if it seems unnecessary to have a join for a one to one relationship (usually it is, not always), then flatten it. In either case, the data should stay in its respective model. That said, you should use the Student model if you handle it in the Student table.
If many (one to many relationship), I'd advise putting it in the Student_group table and leaving it in that model as well.
All in all, the model should be a direct reflection of the data it's representing. You could make some methods inside your Student model to make it easier to get the date, for example. However, I'd personally handle that date inside of the proper model, Student_group. As mentioned, the model should be a direct representation of the data. Again, though, there's nothing wrong with making things a bit easier by creating some methods that help out the developer.
I am creating a database that allows me to save the data to a json online.
I have problems connecting the teams between two tables, the table structure Fixture is as follows:
Table Design teams:
My problem is that I want to load the Fixtures of a given team, for example, I want to load the fixtures of Wolfsburg. Now I'm thinking of being able to exploit the attribute CODE in its teams table, but I do not have this attribute in the table Fixtures and would not know how to connect it as the Fixtures are downloaded from a JSON as you see in the image.
The json presents a link between the team's fixture but concerns the relative links to each team and not a foreign key.
How can I overcome this problem?
Your tables only has homeTeamName and name as common value. You can try to do join on them, but it will be slow and not reliable. I don't see any other way as there is no ID in each table.
Let me start with a simple example to show how my data is structured. There are four tables, Employee, Store, Department, and Employee_Department_Permissions.
Departments belong to Stores (for example, the Department table might contain a record for the dairy department of store 5). Employees are given the right to work in Departments through the Employee_Department_Permissions table, which contains the Employee id and Department id.
Let's say an employee can log in to my application and view a list of every store in the database. Next to each store, I want to print out how many departments they can work in at each store. I have an Employee model with a mapper that provides the fetchAll method to accomplish the first part.
But, where should I find out how many departments an employee can work in? In my model wrapper, I can call findDependentRows to do this. Or, I could do it in my controller with raw Zend_Db_Select calls. A third option I was considering would to be just add a column to the Employee table that holds this information, but then I'd need to update a second table when Employee_Department_Permission is modified.
Thank you in advance for any advice.
As a very general rule of thumb, I would suggest you try keep the controller as free as possible from fetching information for the views. This is a task best handled in the model.
Sure it's easy to just fetch from controller, I mean, since we are there processing a request, it would be so simple to just do a quick fetch and push that off to the view. This is where dicipline comes into play. As your application grows you will appreciate having the clean separation this methodology offers you if applied.
My 2 cents, happy coding to you friend.
I have a site that scrapes all the episodes from tv.com from certain series.
So my database has a User table, a Show table, an Episode table, a Show_User table (to associate shows with users, HABTM), an Episode_Show table (to associate episodes with shows, HABTM), a Episode_User table (to associate episodes with shows, only as a way of marking them as 'watched').
Now I want to add a way of marking an episode as 'downloaded' too.
So at the moment, the Episode_User table has two fields, Episode_Id and User_Id. Should I create a new table entirely for this? Or just add a field to the Episode_User table?
I'm using CakePHP's automagic features, and don't particularly want to break it. But if I have to, I have to...
Thanks for any advice.
I don't see why you would want to create a new table for episodes a user has downloaded. To me it would make the most sense to modify the Episode_User table to have a field for watched and a field for downloaded, since it's all relating back to the same pair of entities, users and episodes.
However, any time I've stored information about a relationship between two tables in that manner, I've found that regardless of the framework I'm using, the ORM inevitably become more complicated, but I don't think there's any way around there.
With CakePHP for handling those kinds of complicated situations, read up about the model behavior, Containable. It's not very well documented in the CakePHP book, but is really quite useful in a situation where you need to use the fields in Episode_User, for example, if you needed to find all of the users that had watched a particular episode, but not downloaded it.
Also, it occurred to me, while reading your post, that you could possibly make your data model more simple by having a hasMany relationship between shows and episodes. An episode will never belong to more than one show, so your episodes table could just have another field, show_id, which related back to the show table, and you wouldn't even need the Episode_Show table.
I would like to have categories, and rankings for my content and users respectively, and I am not sure how to go about implementing this using CakePHP conventions?
Do I need to create a model?
That depends entirely on what these categories are supposed to do and not do. You could simply define a number of constants that you use for categorizing stuff. But, are categories...
subject to change? Do you want to add more eventually?
editable? May you want to change their names?
nested?
supposed to have more attributes than just their id? Names, descriptions?
If you answered Yes to any of the above, you'll want to store them as data in the database. This is independent of Cake, it's just sane data modeling. For Cake that means you'll need to create a model. The same goes for ratings.
So you'll have these tables:
users
hasMany ratings
categories
hasMany contents
contents
belongsTo categories
hasMany ratings
ratings
belongsTo users (polymorphic)
belongsTo contents (polymorphic)
You may want to separate user ratings and content ratings into two tables instead of using a combined polymorphic table (which just means that you have an extra column keeping track of whether a rating is for a user or for content).
i guess you are looking for something like this IF you dont want to use a model:
http://www.dereuromark.de/2010/06/24/static-enums-or-semihardcoded-attributes/
one possible approach to use "enums" for things that maybe only have 1-5 states.
if you have more than 10 or you want to be able to dynamically modify them (label, active/inactive) you will need a separate table and model relation.