From 132bffb2af87dfa40814a2acfad1c01fdf6f6c79 Mon Sep 17 00:00:00 2001 From: Jonathan Date: Mon, 18 Nov 2019 13:31:05 +0100 Subject: [PATCH] Update sqlstyle.guide.md Fix grammar. Proper hyphenation between words. Use HTTPS links. --- _includes/sqlstyle.guide.md | 38 ++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/_includes/sqlstyle.guide.md b/_includes/sqlstyle.guide.md index 02547f8..2216c63 100644 --- a/_includes/sqlstyle.guide.md +++ b/_includes/sqlstyle.guide.md @@ -18,7 +18,7 @@ read—much harder with a physical book. SQL style guide by [Simon Holywell][simon] is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License][licence]. -Based on a work at [http://www.sqlstyle.guide][sqlstyleguide]. +Based on a work at [https://www.sqlstyle.guide/][sqlstyleguide]. ## General @@ -28,7 +28,7 @@ Based on a work at [http://www.sqlstyle.guide][sqlstyleguide]. * Make judicious use of white space and indentation to make code easier to read. * Store [ISO-8601][iso-8601] compliant time and date information (`YYYY-MM-DD HH:MM:SS.SSSSS`). -* Try to use only standard SQL functions instead of vendor specific functions for +* Try to use only standard SQL functions instead of vendor-specific functions for reasons of portability. * Keep code succinct and devoid of redundant SQL—such as unnecessary quoting or parentheses or `WHERE` clauses that can otherwise be derived. @@ -55,10 +55,10 @@ UPDATE file_system * Descriptive prefixes or Hungarian notation such as `sp_` or `tbl`. * Plurals—use the more natural collective term where possible instead. For example `staff` instead of `employees` or `people` instead of `individuals`. -* Quoted identifiers—if you must use them then stick to SQL92 double quotes for +* Quoted identifiers—if you must use them then stick to SQL-92 double quotes for portability (you may need to configure your SQL server to support this depending on vendor). -* Object oriented design principles should not be applied to SQL or database +* Object-oriented design principles should not be applied to SQL or database structures. ## Naming conventions @@ -155,7 +155,7 @@ It is best to avoid the abbreviated keywords and use the full length ones where available (prefer `ABSOLUTE` to `ABS`). Do not use database server specific keywords where an ANSI SQL keyword already -exists performing the same function. This helps to make code more portable. +exists performing the same function. This helps to make the code more portable. ```sql SELECT model_num @@ -224,8 +224,8 @@ Always include newlines/vertical space: large chunks of code. Keeping all the keywords aligned to the righthand side and the values left aligned -creates a uniform gap down the middle of query. It makes it much easier to scan -the query definition over quickly too. +creates a uniform gap down the middle of the query. It also makes it much easier to +to quickly scan over the query definition. ```sql INSERT INTO albums (title, release_date, recording_date) @@ -315,14 +315,14 @@ SELECT CASE postcode ## Create syntax When declaring schema information it is also important to maintain human -readable code. To facilitate this ensure the column definitions are ordered and -grouped where it makes sense to do so. +readable code. To facilitate this ensure that the column definitions are +ordered and grouped together where it makes sense to do so. Indent column definitions by four (4) spaces within the `CREATE` definition. ### Choosing data types -* Where possible do not use vendor specific data types—these are not portable and +* Where possible do not use vendor-specific data types—these are not portable and may not be available in older versions of the same vendor's software. * Only use `REAL` or `FLOAT` types where it is strictly necessary for floating point mathematics otherwise prefer `NUMERIC` and `DECIMAL` at all times. Floating @@ -378,7 +378,7 @@ constraints along with field value validation. * If it is a multi-column constraint then consider putting it as close to both column definitions as possible and where this is difficult as a last resort include them at the end of the `CREATE TABLE` definition. -* If it is a table level constraint that applies to the entire table then it +* If it is a table-level constraint that applies to the entire table then it should also appear at the end. * Use alphabetical order where `ON DELETE` comes before `ON UPDATE`. * If it make senses to do so align each aspect of the query on the same character @@ -411,16 +411,16 @@ CREATE TABLE staff ( ### Designs to avoid -* Object oriented design principles do not effectively translate to relational +* Object-oriented design principles do not effectively translate to relational database designs—avoid this pitfall. * Placing the value in one column and the units in another column. The column - should make the units self evident to prevent the requirement to combine + should make the units self-evident to prevent the requirement to combine columns again later in the application. Use `CHECK()` to ensure valid data is inserted into the column. -* [EAV (Entity Attribute Value)][eav] tables—use a specialist product intended for +* [Entity–Attribute–Value][eav] (EAV) tables—use a specialist product intended for handling such schema-less data instead. -* Splitting up data that should be in one table across many because of arbitrary - concerns such as time-based archiving or location in a multi-national +* Splitting up data that should be in one table across many tables because of + arbitrary concerns such as time-based archiving or location in a multi-national organisation. Later queries must then work across multiple tables with `UNION` rather than just simply querying one table. @@ -1316,13 +1316,13 @@ These are some suggested column data types to use for maximum compatibility betw "Download the guide in Markdown format" [iso-8601]: https://en.wikipedia.org/wiki/ISO_8601 "Wikipedia: ISO 8601" -[rivers]: http://practicaltypography.com/one-space-between-sentences.html +[rivers]: https://practicaltypography.com/one-space-between-sentences.html "Practical Typography: one space between sentences" [reserved-keywords]: #reserved-keyword-reference "Reserved keyword reference" [eav]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model "Wikipedia: Entity–attribute–value model" -[sqlstyleguide]: http://www.sqlstyle.guide +[sqlstyleguide]: https://www.sqlstyle.guide/ "SQL style guide by Simon Holywell" -[licence]: http://creativecommons.org/licenses/by-sa/4.0/ +[licence]: https://creativecommons.org/licenses/by-sa/4.0/ "Creative Commons Attribution-ShareAlike 4.0 International License"