Table/Attribute Modeling

I was interviewing a guy today, and he had obviously been formally schooled in ERM. Every time I run in to that I feel vaguely left out. I don't have a methodology with a cool name that I use. How am I supposed to impress the babes and wow my boss without an important name for what I do? Waaah!

Driving home, it hit me: I *do* have a methodology that I use for schema design; it just doesn't have a cool name. What I need is a cool name! So I tried to think of a name for the methodology I use for schema design; one that was important sounding, so it would impress people, and yet also descriptive of what it is I actually do. I then it came to me:

  "Table/Attribute Modeling."

I do T/AM. What crappy methodology do you use? Oh, that's so 1990s. I pity you.

You see, with Table/Attribute Modeling, I analyze application requirements to generate a set of necessary tables, and a set of attributes for each table. Then I'm able to convert these sets into actual executable SQL DDL, using a proprietary algorithm that I made up just now. You probably couldn't understand it. And voila! There's my schema.

I do it this way because I'm so awesome.

Marshall

PS. In high school biology, we had an assignment once to come up with a mnemonic for the hierarchy
"Kingdom Phylum Class Order Family Genus Species."
A friend of mine did the assignment roughly as follows:

"Whenever I have to recall the classification hierarchy,
I am able to do so by remembering these simple words: Kingdom Phylum Class Order Family Genus Species." Received on Fri Mar 09 2007 - 18:44:23 CST