Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
User Journal

Journal Chacham's Journal: Mini Rant: Silly "standards" on schema 11

Journal by Chacham

Things used to have quality, now companies realize that people in the US are willing to pay for garbage, so they deliver it.

Ignore the world, ignore the world.

I was asked to design a database. After designing it using 3rd normal form, star schema, i was told to "standardize" to six character tablenames, no primary keys, constraints in the program, and something like fifth-normal form when the column is used in more than one table. There are other insanities that only a clueless programmer would enjoy.

Since when did programmers push designers out of the DB?

*sniff*

When will they realize that programmers are gods of UI, but designers should be the DB guys, no matter how tedious the interface.

Let them use a middle-tier if need be, and compromise more than a moderate republican to make everyone happy.

I used to enjoy my job...

This discussion has been archived. No new comments can be posted.

Mini Rant: Silly "standards" on schema More

Mini Rant: Silly "standards" on schema

Comments Filter:
  • Let me agree with you. The database performance and schema needs to be done right, as in a lot of cases, it's the performance bottleneck.

    But now I have to ask - why would 3rd Normal form be any harder to interface with? Is there some MS plug in or something that they're using?

    /me just uses SQL.

    • Given the constraints- looks more like the programmers are into DB2 and refuse to upgrade to anything more modern.

      Ever hear of a RELATIONAL database?!?!?!?
      • > Given the constraints- looks more like the programmers are into DB2 and refuse
        >to upgrade to anything more modern.

        Actually it's sybase, but the constraints come from DB2 mainframe a decade ago.

        We *also* use DB2 (UDB LUW) and some of the constraints were relaxed, or rather, they don't fight too hard. And, i talk to the DBA directly, rather than through the DB programmers.

        >Ever hear of a RELATIONAL database?!?!?!?

        Right-on brotha!

        Want to help me enlighten the world?
        • I would, but I'm stuck with the same problem- a bunch of data analysts who grew up with DB2 and have no idea what third normal form actually means. Our standards are a little bit better than yours- in that foreign keys at least are supposed to have the same name across tables- but the number of tables I've seen with only a very complex- 4 to 5 fields- primary key made up entirely of foriegn keys makes me very sad. And the all-caps with really stupid standardized abbreviations gets to me after a while. Oh
          • in that foreign keys at least are supposed to have the same name across tables

            Well, i like just "Id" as the target of the FK.

            - but the number of tables I've seen with only a very complex- 4 to 5 fields- primary key made up entirely of foriegn keys makes me very sad.

            If it's a hash table (correlation, or whatever) that is perfectly ok.

            And the all-caps

            If not in quotes, SQL gets capitalized anyway. SQL Server breaks that standard by making it case-sensitive.

            with really stupid standardized abbreviations gets to
    • > why would 3rd Normal form be any harder to interface with?

      Because in 3NF, i give *all* "lookup tables" three columns, ID, Name, Description. Then, the referring table simply uses the table name.

      Parent
      ------
      Id
      Name
      Description

      Child
      -------
      Id
      Name
      Description
      Parent (FK to Parent(Id))

      If i did that, they want the name

      Parent
      ------
      Parent_Id
      Name
      Description

      Child
      -------
      Child_Id
      Name
      Description
      Parent_Id (FK to Parent(Id))

      Ideally, i think they'd even prefer 5NF.

      The main reason is, that just by looking at the column nam
      • Oh, Jesus H. Christ! They are doing the whole "natural join" thing!

        It is pure laziness if you ask me. Back in my day we did our own joins by hand. And we didn't use any fancy shmancy cost based optimizers either. We reordered the elements in our query and used hints until we got the plan just the way we liked it and it never got screwed up because someone loaded a whole bunch of data without running statistics. And we liked it!
  • ...constraints in the program, ...

    Are the programmers using an OOP language? If they are, they should understand, for example, that normally an object's data should be private, and only modifiable via the object's interface, so the object can ensure its own internal consistency. The database is sort of like an object, where SQL commands are the accessors and mutators ("getters and setters" just sounds so preschool to me), and its constraints enforce its internal consistency. Having the responsibility for ke
    • >Are the programmers using an OOP language? If they are, they should understand,
      >for example, that normally an object's data should be private, and only >modifiable via the object's interface, so the object can ensure its own >internal consistency. The database is sort of like an object

      Someone gets it! *sniff* You have restored my belief that someone does think.

      That's *exactly* how i view it. Noone else though. (A bunch of Ps i tell you. DB is J work, and they shoulf let Js to the structure, cus
    • BTW [google.com]

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Close