On Jan 7, 5:36 pm, brian <[email protected]> wrote: > It looks to me like you should have > > USERS > id > > SPONSORS > id > user_id > > PERMISSIONS > id > user_id > > Sponsor belongsTo User > Permission belongsTo User > > If not all Users may be a Sponsor, you certainly don't want to have > User.sponsor_id.
After typing a whole lot of stuff disputing your answer, I see your point. Let me explain a little. It's for an personal ad section on a website (mostly html, we only use PHP when needed. We need to replace the old ad section that was build in PHP. In our ad section we want to give our sponsor ads more attention. Our current ad section isn't using a database at all. I now realise I just have a user table and need to look up if that user exists in the sponsor table. If not, it's not a sponsor. So that is clear to me now. I was thinking the other way around. If the sponsor_id in the user table is bigger than 0 then it must be a sponsor. And create a bigger ad on the page. The reason behind the sponsor table is that they have banners all over the site and it would be nice to place some of their ads in the banners as well. But then I would need to do a reverse look up: it's banner 1, so sponsor 1 and then look up the value in the user table to find the user to get the ad. By placing the user_id in the sponsor table it's a lot quicker. I now realise I will need a HABTM between ads, users and sponsors. So your way is better. On the other hand we're not too sure if we're going to do the ads inside the banners. In that case a simple boolean (is_sponsor) in the user table would suffice. It wouldn't matter to know what sponsor it is. It would be nice to have it pre-build. So no matter what we decide later on, it will be there. My other point is the combination hasOne and belongsTo. I found this under the comments of http://book.cakephp.org/view/79 (MilkyJoe) "Appreciate that you have addressed this in the belongsTo section but I think it is worth highlighting in the introduction and also in the hasOne section. [the following comment is for the hasOne section] Let’s set up a User model with a hasOne relationship to a Profile model. After this we will set up a complementary belongsTo relationship." And that's where I get completely confused. Do I always need to do a two way connection? Taking your correction above it would be: Sponsor hasOne User and User belongsTo Sponsor Or is this ONLY when it's a mandatory relation? (like with user/ profile) Which is not my case with sponsor. But it would be the case with the permission model. As every user has a permission, but one permission has multiple users. But my permissions table is more of a helper table, I don't need to do statements the other way around, as I would know who is admin or editor and the rest will be users. so the levels are 1,2 or 3 (or 00, 50, 99). The whole permission table looks like: id level description Could just do without the table as well and hard-code it. Originally I used an enum field in the user-table to show a drop-down box, but I didn't find that in the cookbook, so I decided to play it save and make a separate table. > > If a User may have more than 1 Permission, then you'd need a HABTM join table: > > permissions_users: > permission_id > user_id > If I hard-code the 3 levels, I can do without. As there will be 2 admins and max 3 editors. I would be able to look those users up in phpadmin and change the values. That's why enum is so handy, as you can see the values. > > Is CakePHP always making the joint connections when doing the view, or > > can I still do it the same way and have less calls to the database? > > I'm not sure that I follow. One thing you should be looking at is how > the DB does its query planning whether you use proper joins or the > method you describe. I'd think you'd be best off just creating the > associations. True, but in my book accessing a single table is quicker than accessing multiple ones. If a user logs in, it's easier to know if I need to create a link or not based on a single boolean in the user table rather than do on a complete joint. I could handle joints at a later step. Maybe the boolean is just handy during building and I might not use it in the end. For example a boolean in the user table called has_ad. If the user has no ads I don't need a link saying "edit your ads" But if I call a specific model and it's always doing all the relations it's just pointless to create that single boolean in the first place. As it will not make any difference if I ask for that specific boolean and cakePHP is doing the full statement including all the relations anyways. Like I said, I used to make relations, or joints, at the spot when needed. And not having them pre-defined. So a couple of booleans in a single table is sometimes a quicker way to avoid opening different tables all the time. It's not the correct way of doing it, I know. And I realise that more and more while writing this down. Thanks for the answer, maybe I should dispute myself more often before asking it here. Also been reading on teknoid.wordpress.com and I like his latest post. He explains a lot about making fat models and slim controllers. So I'm a few steps further in understanding how CakePHP works and getting the hang of it. I'm really used to processed programming and the whole MVC structure is new to me so your answer is really apriciated. Daniel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
