Something bothered me about this statement, but I didn't have time to check up on it then.  Today I had a query from our finance department for a set of results on a certain GL account across all our cost centres.  Quite a simple query with 2 tables involved, so I thought I would test the performance on both approaches.

Keeping in mind that we have a fairly large set of data, with just over 160K records in the Chart of Accounts, and just short of 4 million records in the transaction table.  Both of these optimally indexed.

Before I state the results I got, let's just look at the different operations here.

JOIN

• Take every record in the transaction table, and link the appropriate record from the Chart of Accounts to it.
• Compare 2 (varchar) fields in every record to the specified criteria

IN

• Get a subset of records (less than 200) from the Chart of Accounts
• Check if the (int) account id of every transaction is in the subset 

Update:  I've had another instance of this, doing a query across servers, counting records, and I cancelled the query on the join after 90 minutes with no result, the IN took 13 minutes.

                          

Related posts:

1. SQL Joins
2. SSIS – Accessing variables from script components
3. Rugby World Cup Rules for Women

 Get it here

                          

Related posts:

1. Is it worth it trying to maintain multiple blogs?

After playing a bit, I discovered this little problem, which is probably just an incorrect assumption from my side, but I'm sure I'm not the only one that will make this assumption.  If you look at this code sample.

            var value1 = 5;
            var value2 = 42;
            var result = value2 / value1;

            Console.WriteLine("The value of result is " + result);
            Console.WriteLine("value1 is of type " + value1.GetType().Name);
            Console.WriteLine("value2 is of type " + value2.GetType().Name);
            Console.WriteLine("result is of type " + result.GetType().Name);

value1 is initialised using an int/Int32 value, value2 is initialised with an int/Int32 value, which infers that both their types would be Int32 when queried.  Now the result variable, in my mind, is initialised with a double, after all, 42 divided by 5 gives you 8.4, but in this case, because you're dividing an int by an int, the result is given as an int, and the answer is shortened to 8 by default.

To make sure that you get the correct answer, you either have to initialise value2 with a double value as in 

var value2 = 42.0;

or, you have to explicitly declare result as a double, as in

double result = value2 / value1;

either which way will give you a value of 8.4, and a type for result as double.

So, being lazy could bite you if you're not careful.

                          

No related posts.

One is on CodingHorror, by Jeff Atwood, saying that writing code is just like writing, ultimately your co-software developers have to understand what your meaning was, and if they cannot figure it out, you're doing it wrong.

In Jeff's post there is reference to this post by Ned Batchelder, which basically gives you THE rule about removing dead code, which I have to admit, I've been breaking a big percentage of the time.  From now on, in my quest for personal improvement, I will definitely be following both these guidelines.

What are your thoughts on writing good code?

                          

Related posts:

1. Is it worth it trying to maintain multiple blogs?
2. The internet’s impact on gaining knowledge

In the Control Flow script component you access package variables in a similar way to how DTS used to do it.

Dts.Variables("User::FromDate").Value.ToString

 However, trying this in the DataFlow script component only cause some compilation errors and nothing more.

After doing some searching, I eventually found the simple solution that was staring me in the face all along, I just never tried it.

Me.ReadOnlyVariables("User::FileName").Value.ToString()

In both cases you still have to tell the component which variables you're passing in on the property page.
 

                          

Related posts:

1. Always implement the simplest solution
2. SQL – IN vs JOIN
3. The pricing of luxury goods

The new management system decides which elevator you'll be using when you push the button.  It has a nice big arrow above the lift door that lights up while you're waiting, and then starts flashing when the elevator arrives, so the moment you push the button you know which elevator to go stand in front of.  Only sometimes the system realises that the particular elevator is in use between other floors, and then switches to another.

At ground floor level they've installed a set of buttons for each floor in the building, and the system then lets you know which elevator will stop on your floor.  The problem here is that most people don't even bother looking, and just storm into the first elevator that arrives.  You just have to wait for the first stop before you can push your floor button again to make the elevator stop there.

I have no idea how the system calculates which elevator to use, but what I do know is that the average wait time has gone from 30 seconds to about 3 minutes. Surely the developers of the management system should have tested and timed the new system in a real building, preferably their own.  Why try to predict which elevator to use if you can just stop the first one that comes past going in the right direction.

The insides of the new elevators look very nice, but they're still just as shaky as what they used to be.  The only improvement I can really see here is that you can now switch off buttons that were pressed by mistake.

 What I'm getting to here, is that, hopefully, when you get a brilliant idea for your system as the developer, you actually do some homework on the usability of the feature before implementing the changes into your production environment.  I've seen many users hampered by a design decision a developer took, because it would be cool to design, instead of thinking what would benefit the users.

                          

Related posts:

1. Always implement the simplest solution
2. Career Paths for Programmers by John Bennett
3. Use a bit of common sense in traffic

                          

No related posts.

Link to EZWeb guy: Jeffrey Palermo [C# MVP] : How to produce a software product quickly, part 3 - level 300

                          

Related posts:

1. Becoming a grand-master
2. How far can we trust software awards
3. Starter