Am 2008-09-24 um 19:49 schrieb Paul McNett: > No, the biz shouldn't be aware of the ui at all. If it were me, I'd > keep > the PK invisible from the UI (and keep it meaningless), and just > define > another field for the abbreviation field that may well be unique but > isn't *the* pk.
Just to add another example where I use manual PKs all the time (and wouldn't like to change that): Geographical lookup tables for countries or cities (PK: TLD, car/state/ postal code) - I want to find "D" or "de" in my address entry, not some index that I would have to look up itself! In some applications even product IDs (e.g. ISBN, EAN...) make sense as PKs. E.g. in one of my web projects a publishing house uses short codes for its magazines; a lot of other tables relate to them; it's only that one lookup table that uses these codes as PK, but so we get understandable relations everywhere and reduce the need for joined queries, because the editors know their codes. (For I use dabo only for GUIs and write database frontends with web frameworks, it doesn't matter for me what dabo does, but I consider it a drawback if you can't allow for your own PK entries.) Greetlings from Lake Constance! Hraban --- http://www.fiee.net https://www.cacert.org (I'm an assurer) _______________________________________________ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
