Thanks, at first glance this looks like a good set of notes to skim over. I wouldn't spend a tremendous amount of time trying to deeply understand the query op

Thanks, at first glance this looks like a good set of notes to skim over. I wouldn't spend a tremendous amount of time trying to deeply understand the query optimization details. My experience has been that being able to grab out low hanging fruit (ie, are the right indexes being used by the query optimizer, check the plan your RDBMS generates) is more helpful. Most people will never need to think about query optimization as in the notes. Understanding indexing and index selectivity is probably a bigger deal for most apps these days. At least, it seems that I come across many more read intensive apps than high transaction rate apps. But I'm a data warehouse app guy usually. I'd also strongly recommend the Joe Celko books for really building up your SQL chops. Once you have a intermediate understanding of your RDBMS backend and SQL, you'll have all the knowledge you'll need for 90% of db development and know how to investigate the other 10%. I have typically joined projects after the db has been designed. I need to work on being able to quickly refactor table designs to cleanup and enforce constraints. My gut feel is that the best way to do this is to first define a data access layer via some type of procedural API to the other devs on a project and then cleanup the backend design on the side while the project goes forward. Now, if only SQL had the ability to define and dynamically build first class functions as well . . . I could do some snazzy stuff much quicker . . .