Wiki change, and formating change

Author: kevinmartintech

Development Application Settings/Red Gate/SQL Prompt/Styles/Kevin Martin-b9530d2c-850d-46b0-b8b4-51a5899a376e.json

@@ -3,9 +3,6 @@
     "id": "b9530d2c-850d-46b0-b8b4-51a5899a376e",
     "name": "Kevin Martin"
   },
-  "whitespace": {
-    "wrapLinesLongerThan": 150
-  },
   "lists": {
     "placeFirstItemOnNewLine": "always",
     "alignSubsequentItemsWithFirstItem": false,
@@ -18,7 +15,8 @@
   "parentheses": {
     "parenthesisStyle": "expandedSplit",
     "indentParenthesesContents": true,
-    "collapseParenthesesShorterThan": 35
+    "collapseShortParenthesisContents": true,
+    "collapseParenthesesShorterThan": 120
   },
   "casing": {
     "reservedKeywords": "uppercase",
@@ -73,7 +71,7 @@
   },
   "insertStatements": {
     "columns": {
-      "parenthesisStyle": "compactSimple",
+      "parenthesisStyle": "expandedSplit",
       "placeSubsequentColumnsOnNewLines": "ifLongerThanMaxLineLength"
     },
     "values": {

docs/findings/TableConventions.md

@@ -625,6 +625,8 @@ A normalize table design like addresses and phone numbers in separate tables all
 
 You should always normalize the database schema unless you have a really good reason not to. Denormalizing has been performed in the past with the saying "Normalize until it hurts, denormalize until it works". Denormalization almost always leads to eventual issues. Denormalization complicates updates, deletes & inserts making the database difficult to modify. We have tools like indexes or materialized views and covering indexes to remediate performance issues. There are query rewriting techniques that can make queries more performant. 
 
+A legally binding entity like a contract that will be created as an immutable snapshot can contain redundant data. This helps with possible future reprinting of documents. Consider using an auditable append-only Ledger table.
+
 If data is denormalized there are methods of keeping denormalized or duplicated data values correct. The data should be strongly consistency instead of eventually consistent.
 
 Strongly consistent is with the use of transactions that will not allow the data to be out-of-sync like in stored procedure, triggers are the next best option, but triggers have performance issues.