Commit a94f023

authored

Merge pull request #385 from EmergentSoftware/dev

Wiki change, and formatting change

2 parents c10982f + fe79abc commit a94f023Copy full SHA for a94f023

File tree

-5

lines changed

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

-5

lines changed

Lines changed: 3 additions & 5 deletions

Original file line number	Diff line number	Diff line change
`@@ -3,9 +3,6 @@`
`3`	`3`	`"id": "b9530d2c-850d-46b0-b8b4-51a5899a376e",`
`4`	`4`	`"name": "Kevin Martin"`
`5`	`5`	`},`
`6`		`- "whitespace": {`
`7`		`- "wrapLinesLongerThan": 150`
`8`		`- },`
`9`	`6`	`"lists": {`
`10`	`7`	`"placeFirstItemOnNewLine": "always",`
`11`	`8`	`"alignSubsequentItemsWithFirstItem": false,`
`@@ -18,7 +15,8 @@`
`18`	`15`	`"parentheses": {`
`19`	`16`	`"parenthesisStyle": "expandedSplit",`
`20`	`17`	`"indentParenthesesContents": true,`
`21`		`- "collapseParenthesesShorterThan": 35`
	`18`	`+ "collapseShortParenthesisContents": true,`
	`19`	`+ "collapseParenthesesShorterThan": 120`
`22`	`20`	`},`
`23`	`21`	`"casing": {`
`24`	`22`	`"reservedKeywords": "uppercase",`
`@@ -73,7 +71,7 @@`
`73`	`71`	`},`
`74`	`72`	`"insertStatements": {`
`75`	`73`	`"columns": {`
`76`		`- "parenthesisStyle": "compactSimple",`
	`74`	`+ "parenthesisStyle": "expandedSplit",`
`77`	`75`	`"placeSubsequentColumnsOnNewLines": "ifLongerThanMaxLineLength"`
`78`	`76`	`},`
`79`	`77`	`"values": {`

Lines changed: 2 additions & 0 deletions

Original file line number	Diff line number	Diff line change
`@@ -625,6 +625,8 @@ A normalize table design like addresses and phone numbers in separate tables all`
`625`	`625`
`626`	`626`	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.
`627`	`627`
	`628`	`+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.`
	`629`	`+`
`628`	`630`	`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.`
`629`	`631`
`630`	`632`	`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.`

Comments

(0)