Results 1 to 4 of 4
  1. #1
    3 Star Lounger
    Join Date
    Aug 2002
    Location
    Leuven, Vlaanderen, Belgium
    Posts
    322
    Thanks
    9
    Thanked 0 Times in 0 Posts

    Data standardisation & exchange: where to start (All)

    Dear members of the board,
    I hope I'm in the right place here with this question... which isn't urgent at all, just an issue linked to an idea bubbling in my mind.

    I might start a debate about a data exchange standard for (to start with: the highest ranked) pro cycling results. Partners could range from the professional leading organisation (www.uci.ch), on-line database and website managers down to plenty of amateurs and hobbyists (to achieve a maximum supporting area).
    Goal: *many* people all over the world spend plenty of time on the same 'monkey job', which is: entering the same race results in their own databases, using it for their own analysis, reports, websites, games, whatever... There would be a hughe benefit if someone could enter those data once and those data could then, thanks to a standard, be freely distributed to all who's interested... (that's my starting point...)

    Before heading into XML (which, correct me if I'm wrong, I consider a technical issue at this moment), I'm looking for information about the 'working process': what steps need to be taken, in which order, with attention to which pitfalls & issues, in order to achieve such a standard and, in a second step, guidelines for partners who want to implement the exchange via XML in their work/hobby processes & databases.

    A short 'XML for IT-managers' handbook provided me a bit of a start (dealing not with the technical but rather with the management issues). But I hoped there might be some other on-line sources about how to deal with such projects available too...
    So my question is: can anyone provide me some links or information about this, or maybe even an existing project which might be worth looking at?
    Thank you in advance!

  2. #2
    3 Star Lounger
    Join Date
    Aug 2002
    Location
    Leuven, Vlaanderen, Belgium
    Posts
    322
    Thanks
    9
    Thanked 0 Times in 0 Posts

    Keys - Re: Data standardisation (...)

    Meanwhile, I've a more precise question: why should I *not*

  3. #3
    Plutonium Lounger
    Join Date
    Mar 2002
    Posts
    84,353
    Thanks
    0
    Thanked 29 Times in 29 Posts

    Keys - Re: Data standardisation (...)

    The main reasons for using an automatically generated number as primary key are convenience and economy.

    Convenience:
    <LI>An AutoNumber is automatically assigned as soon as the user enters something in a new record, so the unique identifier is immediately available.
    <LI>Except for the occasional glitch, an AutoNumber is guaranteed to be unique, so you don't need to write code to check for uniqueness.
    <LI>An AutoNumber cannot be edited by the user, so the user can't mess it up.

    Economy:
    <LI>An AutoNumber only uses 4 bytes per record in the main table and 4 bytes per record in each table with a foreign key referring to it.
    <LI>A meaningful primary key will usually be a text field and be much longer; this text value will be stored in the main table and in each table with a foreign key referring to it.

    But there is no hard and fast rule against using meaningful values as primary key. It depends on the situation - you, as designer, must use your own judgment. If a meaningful key makes development much easier than an AutoNumber, go ahead and use it.

  4. #4
    2 Star Lounger
    Join Date
    Feb 2002
    Location
    Blacktown, Sydney, New South Wales, Australia
    Posts
    175
    Thanks
    1
    Thanked 0 Times in 0 Posts

    Keys - Re: Data standardisation (...)

    I totally agree with Hans. I have used 'meaningful' keys at a users request only to discover down the track that a different meaning is being inferred, or a new meaning needs to be incorporated. I usually ask the question, 'Why does your key need to be meaningful?" If it is to refer to something by a label that is already widely known, then that is a valid answer. But if the 'meaning' being built in is descriptive, then ask the user if he/she wants to exclude a description field. If the answer is No as it usually is, advise that you are storing the same data twice, (and usually in adjacent fields, as the description invariably follows the key in database design).

    I then advise the user, that I will hide the Key Field being generated automatically in combo boxes etc, so the user will only see the description anyway.

    Having said all this, Hans's advice is very good. If there is a legitimate reason to use a 'meaningful' key then do so, otherwise a autonumber key is very useful.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •