Work? Maybe later.

No, I'd love to have a job right now. But it's not like I don't have the opportunity to do some work without a job. Just yesterday (two days ago now, technically), I helped Christina with some code, in the office, even though I don't work there anymore. *dust shoulders*

I turned in my application for Advancement Systems Manager at Western Oregon University, and stopped by University Computing Services to see if Jing and Christina needed a break, and we could go get coffee. Turns out Jing was taking the day off to celebrate China's National Day (60 years of the new nation), and Christina was busy doing a bubble sort of a PL/SQL array of names. I helped with the PL/SQL code (managed to avoid entering another infinite loop), and we went and got coffee.

Basically, all I did was suggest she copy her test case that she got to work more closely. This is something I actually learned from David Olson. When testing code, copy it exactly, and try to get that to work, then make small changes, test them, etc.

As much as everyone hates him, he knows how to get a program to run, even if he doesn't know how to write the code himself, or how it works, and he taught me that much. (He taught me how to effectively copy code, and I imparted Christina with a taste of that knowledge.) He's the most dislike professor I've met at our school, and while I used to stand up for him, I've caved and go ahead and rag on him like everyone else.

Just for the record though, I learned a lot. Mostly though, I learned how to learn on my own from him. And that's more valuable than any theory or piece of code, because I can use it to lead me to new theories and new types of code. ;) So thanks, Dave. (y)

Anyways, pray I get the job. I'm ready to go back to work.

1:1 Relationships

So, I'm writing this Student Programmer Orientation and Training (SPOT) program for work. I'm at a part where I am writing some basics about database design. Specifically I'm writing about relationships. More specifically I'm writing about 1:1 relationships.

The issue is this: 1:1 relationships are really the most complicated IMO. They can be done either like 1:N, or like N:N. Of course when you use a third table to describe the relationship (like N:N) this is more normalized. But using a foreign key, like in a typical denormalized 1:N, is much more common.

At first I didn't realize this. I though, "oh, I'll start with 1:1, go to 1:N, and then do N:N." But I ended up just moving 1:1 to the end, since it could be done like either of the other two. I realize now I left out the part where a 1:N relationship can be described with a third table, but maybe I'll put that in a quiz to see if they can figure it out on their own. (smirk)

Also, its kind of hard to come up with examples, in my opinion. I used Oregon Drivers License record and Social Security record as my two records that have a one to one relationship. Since ODL will only be associated with one SSN, and they won't issue an ODL to someone who has a SSN with an ODL already associated with it, this is perfect.

And I've only written one program that actually uses a table with a 1:1 relationship. I guess its common to use when you have a special group of users. I might have to go back and do that. User ID foreign key . . . reason for being serperate from the rest of the table . . . sounds good to me.

Anyways,
:p

Rant # 1

I really love consistency in my program variables. I'm writing in PL/SQL at work now, and our convention is to use pvariablename for all of our procedure parameters. Then we use vvariablename for all of our in procedure variables. It really pisses me off when I'm working on a project with a coworker and she uses a liberal mix of variables starting with p and parameters starting with v.

Also, I really like to handle all my error checking, parsing and stuff on the database side. And she likes to do everything in JavaScript. And our forms are inconsistent. I use three input boxes for a phone number, but she uses 1, with lots of JavaScript control. Again, I control error checking on the server side here, not in JavaScript on the client side.

I think that either way is fine really. I just think that when building a program/website, we should pick a method to do something and use it everywhere instead of just having two or three different types of phone number input fields depending on which part of the app you are looking at.

I bet there are a lot of blogs like this. I seem to get this feeling of frustration quite often while programming, and I'm at a computer with web access, and blogger makes it pretty easy to start a new blog if you want. Lately its almost like, instead of just posting a new blog entry, I'll just make a whole new blog... Should have some option to auto-link all of your blogs if you chose... Maybe I'll build that feature for mine...

Enjoy!