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 -~----------~----~----~----~------~----~------~--~---
