Re: Auto increment

"stu" <smcgouga_at_nospam.co.uk> wrote in message news:b9qgpv$c08$1$8300dec7_at_news.demon.co.uk...
>
> "Tobin Harris" <comedyharris_at_hotmail.com> wrote in message
> news:b9og29$l7ptr$1_at_ID-135366.news.dfncis.de...
> > I think it's realistic to assume that database builders want to have the
> > system help them allocate unique keys where necessary, but perhaps it
> would
> > be helpful to have much more flexibility than the current vendors
provide.
> > For example, what if the database had a 'key engine' that could be
> > programmed to generate meaningful or meaningless keys according to
> specific
> > business rules?
>
> So the problem with a surrogate key is the way it can be implemented? I.e
> Autonumber! So a business key generator that generates meaningful keys is
a
> much better idea?

Personally, I think that part of the problem is not so much implementation, but lack of flexibility. In some cases, autonumbers are handy and good, but at other times they're not, and we're left to build key generators by hand. My team is working on a 50-60 table database (quite big for us!), and I'd like us to find an alternative to autonumbers in some places. Because our tool doesn't provide one, we'll either have to handle key generation using sprocs or triggers, or put that responsibility into another tier. It's not just adding sprocs and triggers though, you need supporting tables and must take care with concurrency, which as I'm not a DBA all seems a touch daunting!

> eg first 3 letters of customer name followed by the date that customer
> entered our DB as opposed to a meaningless ID?

I didn't really mean meaningful 'to-the-eye', but perhaps meaningful to the business in that there are some conventions involved. I'd like a key engine that helps me set up keys for a variety of situations. When working with legacy systems, I have been asked to continue key conventions. Not necessarily ideal from my perspective, but business is business, and if 100 employees and various systems are set-up to handle a given convention, I can't really dictate that the customer pay for that to be replaced with my own convention.

Cheers,

Tobin

> Cheers
> Stu
>
>
Received on Tue May 13 2003 - 14:05:17 CEST