Re: Does it make sense to move this XML to a database?

On 30 Jan 2003 08:32:13 -0800, efeigenb_at_alumni.tufts.edu (Figz) wrote:

>We keep a list of error numbers which each map to a user-friendly text
>description.

Bless you.

[snip]
>....and so on, for every error. This list is now in the hundreds of
>errors. We're starting to look at better ways to store and map these
>error codes.

My first thought was, "Why isn't this just plain text?" You can store a file like this under version control:

 1001::You entered an invalid email address.  1002::You entered a dollar amount less than zero.

And grep is your friend.

Use a couple of lines of awk or perl to generate whatever you need from it--XML (or just the error descriptor part), C or C++ header files, whatever.

>My questions are: Is it better to move this into a database table?

You gain some control over the data; you can even revoke most permissions on that table, and require all changes to go through the project librarian. (Years and years ago, I worked in a shop where only one person could write to the revision control system. I left before he took a vacation.) And you can add a table of "concepts", kind of like a cross-reference index. For error 1001, you might insert "invalid data", "mail", "email" and "address".

>At what point does the size of the xml file begin to degrade the
>performance?

If your developers are inventing new error codes because the XML file is too big to deal with, I'd say you've passed that point, wherever it is. I recall reading that most programmers spend less than 30 seconds trying to find a function in the library before they start writing one themselves. YMMV; functions != error codes != XML.

>The problems with moving to a database table would
>include:
>· Time consuming to import all of them and make necessary database
>changes (Probably are a couple of ways to automate this though)
 

>· Will have to search and replace all existing use of error codes with
>calls to the database

Instead of search-and-replace, you can schedule a job that periodically writes a new text or XML file based on the contents of the table. You're really the only one who can gauge the impact.

>Suggestions for designing a better error code/description system would
>be greatly appreciated. Any tips on what you have done in your
>experiences would be great.

The design really depends on what the error codes are for. So what are they for? Front end app?

-- 
Mike Sherrill
Information Management Systems