Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Tuesday April 29, 2003
01:15 PM

Primary Keys

[ #11910 ]

I've just requested that this be the first line of every new specification we prepare:

Internal database IDs should never be externally visible.

If a customer wants an "ID", I'll be happy to make them one.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • How do you work around that? For example, if you were showing a list of things to a user and wanted them to select something, I'd have internal IDs visible. They'd see:
    I'm not quite sure what the problem is, they could always edit the url to change the ID but there should be no chance that they can work around permissions this way.
    • Re:interesting (Score:3, Interesting)

      Sorry, I was unclear. The id is typically in the URL or in a hidden field and that's fine, but it shouldn't be showing up in a table. It's not information that the user needs or can do anything with, but it can be tiring telling the user that it really doesn't mean anything and "no, you can't change it".

      • Re:interesting (Score:2, Informative)

        That makes more sense now :)

        I worked on a system where the client was paranoid that people were able to see database IDs in hidden fields and change them. I wrote an extra layer that used 8 character random strings as IDs and it was a huge PITA.

  • GUIDs (Score:3, Informative)

    by Theory (10) on 2003.04.29 20:02 (#19596) Homepage Journal

    I think that we might be using GUIDs for objects in Bricolage 2.0, probably using Data::UUID []. It will fascilitate syncing independent Bricolage servers. Of course, database sequence IDs will still be used for primary keys.


  • I would generalize that in a different way: no system-generated unique identifier should ever be interpreted as to its content. In other words, those columns should be used for joins to other tables and nothing else. For example, if you ever find yourself writing "order by" on that column, you're setting yourself up for trouble. As a test, if you're using any kind of SUID, I should be able to substitute 1, -47, or 240981 for any of the values consistently, and no program or user should be any the wiser.