Defensive Database Programming - Red Gate Software

More documents

Recommendations

Info

Chapter 7: Advanced Use of Constraints-- we shall need the test data intact-- to use in other examples,-- so we roll the changes backROLLBACK ;Listing 7-13: Reassigning an active ticket.Also we need to verify that our system works when we modify Developers.DeveloperID column, as shown in Listing 7-14.BEGIN TRANSACTION ;PRINT 'Original Data in Tickets table' ;SELECT TicketID ,AssignedToDeveloperID ,DeveloperStatusFROM dbo.Tickets ;UPDATE dbo.DevelopersSET DeveloperID = -1WHERE DeveloperID = 1 ;PRINT 'Data in Tickets table after DeveloperID was modified';SELECT TicketID ,AssignedToDeveloperID ,DeveloperStatusFROM dbo.Tickets ;ROLLBACK ;Original Data in Tickets tableTicketID AssignedToDeveloperID DeveloperStatus----------- --------------------- ---------------1 1 Active220
Chapter 7: Advanced Use of Constraints(1 row(s) affected)(1 row(s) affected)Data in Tickets table after DeveloperID was modifiedTicketID AssignedToDeveloperID DeveloperStatus----------- --------------------- ---------------1 -1 ActiveListing 7-14: The modified Developers.DeveloperID value propagatesinto the Tickets table.As we have seen, when we modify Developers.DeveloperID, the change propagatesinto the Tickets table. This was not one of our requirements, but is a side effect of theON UPDATE CASCADE clause. We'll modify our solution later, and this side effect willbe gone.So far, our constraints have worked as expected in all the cases. Of course, if we wererolling out a production system, our testing would be far from complete. For example,we should test cases when more than one ticket is assigned to a developer, cases wherewe modify more than one row, and the case where we modify the Developers.DeveloperIDcolumn for more than one row. However, we shall not demonstrate completetesting here; the solution presented here passes complete testing, and I encourage you totry out different test cases as an exercise.Removing the performance hit of ON UPDATECASCADEWe need to discuss in a little more detail the ON UPDATE CASCADE behavior and itsperformance implications. Whenever a developer's status changes, the correspondingDeveloperStatus column in the Tickets table changes automatically, for all thetickets assigned to that developer. This behavior definitely gets the job done, and ourbusiness rules are robustly enforced. However, we need to ask ourselves the followingquestion: why do we need to update the DeveloperStatus column for closed tickets?Clearly our CHECK constraint only needs to use DeveloperStatus if the ticket is open.221
Page 5 and 6:
Chapter 2: Code Vulnerabilities due
Page 7 and 8:
Enforcing Data Integrity in the App
Page 9 and 10:
About the AuthorAlex Kuznetsov has
Page 11 and 12:
IntroductionResilient T-SQL code is
Page 13 and 14:
IntroductionCh. 02: Code Vulnerabil
Page 15 and 16:
IntroductionSpecific examples demon
Page 17:
IntroductionWhat this book does not
Page 21 and 22:
Chapter 1: Basic Defensive Database
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 57 and 58:
Chapter 2: Code Vulnerabilitiesdue
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75:
Page 78 and 79:
Chapter 3: Surviving Changes to Dat
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
104
Page 106:
Chapter 4: When Upgrading Breaks Co
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 130 and 131:
Page 132 and 133:
Chapter 5: Reusing T-SQL CodeThe Da
Page 134 and 135:
Chapter 5: Reusing T-SQL CodeIt is
Page 136 and 137:
Chapter 5: Reusing T-SQL CodeAverag
Page 138 and 139:
Chapter 5: Reusing T-SQL CodeBEGINS
Page 140 and 141:
Chapter 5: Reusing T-SQL CodeWe als
Page 142 and 143:
Chapter 5: Reusing T-SQL CodeLet's
Page 144 and 145:
Chapter 5: Reusing T-SQL CodeStateC
Page 146 and 147:
Chapter 5: Reusing T-SQL CodeStateC
Page 148 and 149:
Chapter 5: Reusing T-SQL CodeBEGIN
Page 150 and 151:
Chapter 5: Reusing T-SQL CodeSELECT
Page 152 and 153:
Chapter 5: Reusing T-SQL CodeReusin
Page 154 and 155:
Chapter 5: Reusing T-SQL CodeIt is
Page 156 and 157:
Chapter 5: Reusing T-SQL CodeINSERT
Page 158 and 159:
Chapter 5: Reusing T-SQL CodeListin
Page 160 and 161:
Chapter 5: Reusing T-SQL CodeUnique
Page 162 and 163:
162
Page 164 and 165:
Chapter 6: Common Problems with Dat
Page 166 and 167:
Page 168 and 169:
Page 170 and 171: Chapter 6: Common Problems with Dat
Page 209 and 210: Chapter 7: Advanced Use ofConstrain
Page 211 and 212: Chapter 7: Advanced Use of Constrai
Page 219: Chapter 7: Advanced Use of Constrai
Page 255 and 256: Chapter 8: Defensive ErrorHandlingT
Page 257 and 258: Chapter 8: Defensive Error Handling
Page 271 and 272:
Chapter 8: Defensive Error Handling
Page 273 and 274:
Page 275 and 276:
Page 277 and 278:
Page 279 and 280:
Page 281 and 282:
Page 283 and 284:
Page 285 and 286:
Page 287 and 288:
Page 289 and 290:
Page 291 and 292:
show all

Defensive Database Programming - Red Gate Software

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?