Best database-design questions in August 2010

Documenting relational databases (tables, views, functions, triggers)

8 votes

I'm trying to improve the knowledge management of MySQL structures available on a project. By structure, I mean tables, views, functions, procedures, triggers.

All these structures are extracted in .sql files.

I'm looking for a way to document these structures, presenting results à la doxygen in HTML files. For example, I want this tool to group functions in a section, with documentation tags extracted and reformatted to be human-readable added to each function.

I tried looking at doxygen, but it seems it does not support sql yet.

I need tools that can be run in batchs, using a linux environment.

What tools do you know ? Do you have advices on how to achieve good knowledge management of databases ?

Thanks !

I found pldoc. I will try it to see if it fits my needs.

Is normalizing the gender table going too far?

6 votes

I am not a database guy, but am trying to clean up another database. So my question is would normalizing the gender table be going too far?

User table:
userid int pk,
genderid char(1) fk
etc...

gender table:
genderid char(1) pk,
gender varchar(20)

Now at first it seemed silly to me, but then I considered it because i can then have a constant data source to populate from or bind from. I will be using WPF. If it was another framework I would probably avoid it, but what do you think?

Whether or not you choose to normalize your table structure to accomodate gender is going to depend on the requirements of your application and your business requirements.

I would normalize if:

  • You want to be able to manage the "description" of a gender in the database, and not in code.
    • This allows you to quickly change the description from Man/Woman to Male/Female, for example.
  • Your application currently must handle, or will possible handle in the future, localization requirements, i.e. being able to specify gender in different languages.
  • Your business requires that everything be normalized.

I would not normalize if:

  • You have a relatively simple application where you can easily manage the description of the gender in code rather than in the database.
  • You have tight programmatic control of the data going in and out of the gender field such that you can ensure consistency of the data in that field.
  • You only care about the gender field for information capture, meaning, you don't have a lot of programmatic need to update this field once it is set the first time.