When you see examples of spaghetti code, you wish it came with a warning: "Abandon all hope, ye who enter here!"

Spaghetti code is a term used to describe code that is tangled and difficult to trace and maintain. No one wants to update spaghetti code because it is hard to tell what it does, how it is used, who uses it, and what the impact of changing it might be.

Frequently I encounter SQL servers and databases in enterprises that contain spaghetti code - usually in the form of three- and four-part object references (cross-database and cross-server references), or databases that lack clear, well-defined interfaces using schema names and database roles.

Three- and four-part name references in your SQL are a big "code smell" (and I don't mean a nice smell)! They are an indication that you have bad coupling and poor cohesion; coupling and cohesion are coding principles that are well-known by software developers and that database developers *should* also practice.

In this session I will show the most grievous bad practices, what sorts of problems and constrictions they cause, and how they can be re-written to achieve much better cohesion and looser coupling across all data in an enterprise.

Any DBA or developer that uses more than two part table or view names in their queries or stored procedures should attend!