In my role I review a wide variety of SQL code.<\/p>\n\n\n\n
Some is highly professional that is above my skill level so I absorb as much learning as I can from it.<\/p>\n\n\n\n
On the other side is self taught SQLers from the business world who are trying to build weird and wonderful reports with SQL held together with sticky tape and don’t truly comprehend the code that is written.<\/p>\n\n\n\n
An example – I see the following a lot with people who don’t understand the data and trying to program stability in their code like this:<\/p>\n\n\n
\nSELECT \n A.BDATE,\n A.ID,\n A.CUST_ID,\n C.CUSTOMER_NAME,\n C.PHONE\nFROM dbo.ACCOUNTS A\nLEFT OUTER JOIN dbo.CUSTOMER C\nON C.BDATE = @DATE\n C.CUST_ID = A.CUST_ID \nWHERE\n A.BDATE = @DATE AND\n A.ACCOUNT_TYPE = 'XX';\n<\/pre><\/div>\n\n\nThis means if for some reason if there is an integrity problem between ACCOUNTS and CUSTOMER; they will still get the account data on the report.<\/p>\n\n\n\n
The problem arises when the business requirement of the report evolve and the developer needs to filters on the left joined table. <\/p>\n\n\n\n
For instance – “Report on Accounts on type XX but remove deceased customers so we don’t ring them” <\/p>\n\n\n\n
I quite often see this:<\/p>\n\n\n
\nSELECT \n A.BDATE,\n A.ID,\n A.CUST_ID,\n C.CUSTOMER_NAME,\n C.PHONE\nFROM dbo.ACCOUNTS A\nLEFT OUTER JOIN dbo.CUSTOMER C\nON C.BDATE = @DATE\n C.CUST_ID = A.CUST_ID \nWHERE\n A.BDATE = @DATE AND\n A.ACCOUNT_TYPE = 'XX' \n\n AND\n\n C.DECEASED = 'N';\n<\/pre><\/div>\n\n\nWithout knowing it; the developer has broken their “Get all account XX report” business rule by turning their LEFT OUTER JOIN into effectively a INNER JOIN.<\/p>\n\n\n\n
The correct way to write the query is:<\/p>\n\n\n
\nSELECT \n A.BDATE,\n A.ID,\n A.CUST_ID,\n C.CUSTOMER_NAME,\n C.PHONE\nFROM dbo.ACCOUNTS A\nLEFT OUTER JOIN dbo.CUSTOMER C\nON C.BDATE = @DATE\n C.CUST_ID = A.CUST_ID \n\n -------------------------------- \n AND\n\n C.DECEASED = 'N'\n -------------------------------- \nWHERE\n A.BDATE = @DATE AND\n A.ACCOUNT_TYPE = 'XX' ;\n<\/pre><\/div>\n\n\nYou can get a good gauge of the skill level of the developer by checking their LEFT OUTER JOINS. If they using them on every join where you know there is integrity between the two data objects; you can have an educated guess that you’re reviewing a novice developer.<\/p>\n\n\n\n
This is where you have to pay extra attention to their joins and where predicates and make them aware of the consequences of the code.<\/p>\n","protected":false},"excerpt":{"rendered":"
In my role I review a wide variety of SQL code. Some is highly professional that is above my skill level so I absorb as much...<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[13,17],"tags":[],"class_list":["post-862","post","type-post","status-publish","format-standard","hentry","category-code","category-sql"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t