Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • normalization (Score:4, Informative)

    It's worth pointing out that sometimes you can take normalization too far and make something that looks good on paper, but is a pain to worth with.

    For example, I ported an e-commerce site from JSP/MS-SQL to Perl/TT/MySQL and the schema was really nasty. Instead of creating a product table that looked something like:

    product(id, price, name, title, short_description, long_description)

    They split things into multiple tables in case they had to add extra fields in the future:

    product(id, price, name)

    text(p

    • product(id, name, ..., group_name)
      That's fine, you could even have a table of valid group names as primary keys, and make the group in the product table a foreign key to the group table's primary key.

      As for taking normalization too far, I once experienced a table with:

      year(year_id, year_num)
      The year column was a just a serial id, and the year number was the valid years you could search for. So the product table was something like:
      product(product_id, ..., year_id)
      Searching for products from 1965 to 1967 in that schema was a horror :-) I talked them into just creating a year table with just the one field, and making the field in the product table and foreign key to it. It took a little time for them to get it (wait, we don't have to even join to the year table...?).