Yo can define which column is used in the join, see: http://manual.cakephp.org/chapter/models http://tempdocs.cakephp.org/#TOC82250 http://book.cakephp.org/view/66/models#78-associations
On Fri, Feb 15, 2008 at 7:21 AM, villas <[EMAIL PROTECTED]> wrote: > > The end-user reporting application is indeed 3rd Party. It only takes > a few seconds to teach users how to make nicely formatted reports from > tables. However, although IMO the dialogs for joining tables are > fairly straightforward to anyone knowing SQL, it can be quite tricky > for those who are unenlightened. Hence my desire for primary keys > which are meaningful. > > From your answer it seems that Cake would have no problem with my > idea. One of my doubts was whether anyone would propose the > following: > > Contacts > id Lastname Contacttype_ref > > --- -------------- --------------------- > 1 Fred TELE > 2 Joe MEET > 3 Alan MAIL > ....etc > > Contacttypes > id Ref Name Status > --- ----- ----------- ---------- > 1 TELE Telephone Call A > 2 MEET Meeting B > 3 MAIL Email A > ....etc > > Note that Contacttype_ref would be unique, not null, index. But then > the Cake magic would disappear? > > Sorry for this elementary question, but the DB setup is important to > get right at the outset and the 'outset' is where noobies like me are > least knowledgeable. > > > > On Feb 14, 5:58 pm, Baz <[EMAIL PROTECTED]> wrote: > > I'm curious to see some of the other responses, but here's mine. > > > > I don't think I understand what you're trying to accomplish. > > If you build an application in Cake, then no end user sees the resulting > > SQL, what the keys are shouldn't matter. > > > > What I _think_ you're saying is that OUTSIDE of Cake, you're using a third > > party application to do reports with joins? If so, I don't quite understand > > how users can join tables (on char keys or numeric) if they don't know what > > they are doing...Either this 3rd party application knows how to join or it > > doesn't. > > > > But regardless of what your app. can and cannot do, this is not a CakePHP > > specific problem. As far as I am aware, your primary keys can be anything > of > > your choosing. Obvious, if it's not auto-incrementing then you are > > personally going to have to manage how they get set when you add > > Contacttypes, for example. It would be as simple as putting in the field in > > the form. > > > > If not, you'll have SQL errors. This would be a problem in any other type > of > > application. > > > > Again, your intent is a bit vague to me, but regardless the only constraint > > that I am aware of with CakePHP is the the primary key cannot be composite. > > > > > > On Thu, Feb 14, 2008 at 11:44 AM, villas <[EMAIL PROTECTED]> wrote: > > > > > I notice that everyone using Cake seems to use autoincrementing > > > integer primary keys. However this means you always have to join the > > > code files for all queries and reports because the keys don't mean > > > anything (unless you can memorize lots of numbers). > > > > > In the past I have successfully used more recognisable alphanumeric > > > primary keys, and I appreciate that one must manage these manually > > > but it makes end-user reporting much more intuitive. > > > > > e.g. > > > > > Contacts > > > id Lastname Contacttype_id > > > --- -------------- --------------------- > > > 1 Fred TELE > > > 2 Joe MEET > > > 3 Alan MAIL > > > ....etc > > > > > Contacttypes > > > id Name Status > > > --- ----------- ---------- > > > TELE Telephone Call A > > > MEET Meeting B > > > MAIL Email A > > > ....etc > > > > > The users are using an end-user reporting application and will be able > > > to make a simple query on the Contacts table which will provide the > > > info he needs without making any joins. In fact the user wouldn't > > > need to know about joins unless for example he needs to get the > > > 'status' in which case his supervisor can assist. > > > > > My questions are: > > > 1. Is the 'cost' of having non-standard primary keys too great a > > > price to pay in terms of losing some of Cake's built-in power? I'm > > > not even sure what functionality we might miss. > > > > > 2. Clearly the above tables are greatly simplified; the real-life > > > tables would require many joins. If I don't use the alphanumeric > > > keys, I would have to go around and teach a lot of people how to join > > > up the tables to make their reports. Does everyone advocate teaching > > > end-users about the principles of the SQL SELECT? > > > > > I am sure that I'm not the first to have this dilemma, but maybe > > > someone might give me a bit of advice based on their own experience? > > > > > D > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" 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 -~----------~----~----~----~------~----~------~--~---
