Subject | Re: Auto-increment and generators |
---|---|
Author | h_urlaf |
Post date | 2004-02-10T20:35:57Z |
--- In firebird-support@yahoogroups.com, "Brian L. Juergensmeyer"
<brianj@c...> wrote:
application; it's behaviour cannot be changed without much grief from
our users.
must also be unique.
It could be phone numbers, it could be case IDs for a lawfirm, etc.
All we know is that their numeric, and that they will be unique.
application will have to take care of setting an appropriate value.
but I'll still just have the app logic decide. The UNIQUE DEFAULT NULL
will take care of the uniqueness; what remains is that I'll have to
device a app-side way to generate 'random' unique IDs when the user
wants that (and it'll have to be the default behaviour).
another (only slightly related) issue I posted a few days ago. Damn.
Emiliano
<brianj@c...> wrote:
> In my opinion, the problem here is in the design of the app.*grin* I'm not going to argue against *that* ;) It's an existing
application; it's behaviour cannot be changed without much grief from
our users.
> You're trying to bend over too far backwards to guarantee a uniqueI have that, it's the user id. A user also has a mailbox ID, which
> key entry for your table. I think your best bet would be to add an
> ID field that only and forever uses a generator to guarantee a
> unique id.
must also be unique.
> If you feel the need toWhat the 'meaning' of the mailbox is is up to the customer to decide.
> do so, set up a UNIQUE index or constraint on the relevant fields
> that you mentioned. Then, just do a SELECT FOO FROM MAILBOX WHERE
> (ID=A_ID OR PHONE=A_ID OR PERSONNEL_ID=A_ID).
It could be phone numbers, it could be case IDs for a lawfirm, etc.
All we know is that their numeric, and that they will be unique.
> Trying to fight the generators like this is going to cause youI suppose. I'll just set the mailbox to UNIQUE but allow NULL. The
> nothing but grief.
application will have to take care of setting an appropriate value.
> And I sincerely hope that, if you do try to do a BEFORE INSERT ORI expected that. I'm not going to be doing many inserts on that table,
> UPDATE trigger to check for uniqueness, that you:
> A: aren't doing much inserting (as doing a bulk insert that triggers
> a WHILE (EXISTS.... on each insert would be incredibly painful from
> a performance perspective),
but I'll still just have the app logic decide. The UNIQUE DEFAULT NULL
will take care of the uniqueness; what remains is that I'll have to
device a app-side way to generate 'random' unique IDs when the user
wants that (and it'll have to be the default behaviour).
> andI can't guarantee it, so that means it's out. That also answers
> B: can guarantee that only one user is able to update your mailbox
> table at once. If you can't guarantee that, you are going to get
> into troubles anyway.
another (only slightly related) issue I posted a few days ago. Damn.
Emiliano