in

Utah .NET User Group

Home of Utah's professional .NET developers.

Bryan Hinton's Blog

October 2005 - Posts

  • Oracle and Indexes - Some tips

    Tom Kyte is one of the best in the business when it come to Oracle and is the Tom that many people rely on at Ask Tom. Here is a link to an article that has him talking about some common myths about Oracle indexing. I get questions on these exact things often. I even have people who have worked with Oracle for years that try to tell me that some of these myths are true. I don’t always have time to provide them examples to back up my point so having Tom out there to come in and settle the dispute is nice.

    Here is a quick summary of his tips

    • Nulls are not completely stored in B*Tree indexes - (Null, Null) in one row is not the same as (Null, Null) in another row - by definition Null is not equal to another null. When you aggregate it thought they group together. Also - if you have an index that is based on all NULLABLE columns and you do a query looking where one or more of the columns are null - the index cannot be used
    • Views are indexed by indexing the base tables the view is based off of - the optimizer will break the view down and develop an execution plan based on the base tables
    • Unindexed foreign keys are the biggest cause of deadlocks that Tom sees - so index them!
    • 6 most common reasons your index is not being used - nothing earth-shatteringly new here, but great things to remember
    • Index space IS reused (always) and can be automatically reclaimed (under certain conditions)
    • The column with the highest selectivity (most distinct values) need not be the first column in the index - from a space perspective they use the same space - the most important thing to consider most of the time is HOW you query the table - without understanding the most common access methods - effectively indexing a table is difficult. Also he points out that indexes that go from least selective to most are more compressible, save space, and reduce I/O making the case if you are using Index Key compression to go that route for building your indexes.

     

    Technorati tags: ,
  • Software Project Estimation

    Great article by David Anderson on project estimation - he is an agile guy so he tends to a be a little harsh on the traditional PLC estimating techniques - he talks about alternative methods to estimating based on Agile and FDD (Feature-Driven Development). My experience with project estimation is that most of the teams (myself included) don’t know how to do it really well and so we guess and then work ourselves to death because we always estimate optimistically (or get surprised by the extreme amount of process that gets in the way and slows us down). David speaks to the waste of effort from a customer perspective and a developer perspective in estimating effort because the end result is numbers that don’t mean a whole lot. On the other hand he says working the requirements and breaking them down into pieces that gives us a work detail as well as helps us in understanding more completely what the customer is asking for. So focus on analyzing the requirements and outputing information surrounding them rather than focusing on some number that your are supposed to give.
    There is one thing from what David says that I don’t understand in relation to Agile (specifically XP) development efforts - don’t you buy definition when you go through planning games - identify how many tickets (or whatever you call them) are available and how much each use case (feature) defined by the users will cost in tickets? To me that seems to be the same form of estimating that David is denouncing.
    I drill down into David’s previous post on agile estimating as well as the comments (which you should also read because it has some good stuff in it as well) - he expounds a little more that his estimating should be more lightweight and should deal in terms of number of bugs that someone can do in a specific window (what he calls velocity I think) with an accounting for variation in velocity. I suppose that maybe this speaks back to the goal of the FDD model and XP to break things down in pieces and interate quickly over the smaller pieces of work thus supporting a lighter weight estimating cycle. I am certainly not an expert on any of this - but I am learning more and more all the time which hopefully helps me long term - one of the challenges is changing the culture (or adjusting to use a less negative term!) to be more software oriented and leveraging the software development knowledge and best practices within the teams that I work on.

    Why Estimates are Muda

     

  • Comparison of CVS versus Source Code Control in Team Foundation Server

    I am cleaning out my blog folder after getting quite behind in all the things I have been wanting to post - Here is some good stuff on the new source code system in VS2005 (Team System version) - I might add that MS now has two solutions - VSS and TFVC (Team Foundation Version Control)
    Comparison by one of the designers/developers of TFVC between TFVC and CVS - CVS and TFVC Comparison

     

     

    Technorati tags: , ,
Copyright © 2000-2007, Utah .NET User Group
Powered by Community Server (Commercial Edition), by Telligent Systems