Add BETWEEN recommendation

Author: ktaranov

SQL Server Name Convention and T-SQL Programming Style.md

@@ -199,21 +199,22 @@ More details about SQL Server data types and mapping it with another databases a
 
 This is only recommendations! But it is consistent for choosing only 1 function from possibles alterntives and use only it.
 
-| Not Recommended | Recommended | When and Why | More details |
-|-----------------------|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|----------------|
-| [`!=`][12] | [`<>`][12] | `<>` is [`ANSI`], `!=` not `ANSI`, [`<>` and `!=` are identical][13] | [13] |
-| [`CONVERT`][10] | [`CAST`][10] | `CAST` is [`ANSI`] | [14],[15] |
-| [`ISNULL`] | [`COALECSE`] | `COALECSE` is [`ANSI`] and supports more than two arguments, `ISNULL` has dangerous behaviour with possibility to implicit triming string | [16],[17] |
-| [`DATEDIFF`] | [`DATEADD`] | The predicate `MyDateTime < DATEADD(SECOND, -1, GETUTCDATE())` syntax is [`SARGable`] | [18],[19] |
-| [`SELECT`] | [`SET`] | Using `SET` (is [`ANSI`]) instead of `SELECT` when assigning variables due to properly work with `Msg 501 Subquery returned more than 1 value` | [20],[21],[22] |
-| [`STR`] | [`CAST`][10] | `STR` is not [`ANSI`], extremly slow, don't use more than 15 digits, and has rounding problem - use `CAST` plus concatenate instead `STR` | [23] |
-| [`ISNUMERIC`] | [`TRY_CONVERT`] | `ISNUMERIC` can often lead to data type conversion errors, when importing data. For SQL Server below 2012 use `WHERE` with `LIKE`. | [24] |
-| [`GETDATE`] | [`SYSUTCDATETIME`] | Daylight Saving Time and other factors can play havoc with our dates and times, rounding to the nearest 3 milliseconds. | [25] |
-| [`GETUTCDATE`] | [`SYSUTCDATETIME`] | Daylight Saving Time and other factors can play havoc with our dates and times, rounding to the nearest 3 milliseconds. | [25] |
-| [`SYSDATETIME`] | [`SYSUTCDATETIME`] | Daylight Saving Time and other factors can play havoc with our dates and times, rounding to the nearest 3 milliseconds. | [25] |
-| [`CURRENT_TIMESTAMP`] | [`SYSUTCDATETIME`] | It's too similar to the poorly-named TIMESTAMP data type, which has nothing to do with dates and times and should be called ROWVERSION. | [26] |
-| [`DATETIMEFROMPARTS`] | [`DATETIME2FROMPARTS`] | It's too similar to the poorly-named TIMESTAMP data type, which has nothing to do with dates and times and should be called ROWVERSION. | [26] |
-| [`ISDATE`] | [`TRY_CONVERT`] | `ISNUMERIC` can often lead to data type conversion errors, when importing data. For SQL Server below 2012 use `WHERE` with `LIKE`. | [26] |
+| Not Recommended | Recommended | When and Why | More details |
+|-----------------------|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------|
+| [`!=`][12] | [`<>`][12] | `<>` is [`ANSI`], `!=` not `ANSI`, [`<>` and `!=` are identical][13] | [13] |
+| [`CONVERT`][10] | [`CAST`][10] | `CAST` is [`ANSI`] | [14],[15] |
+| [`ISNULL`] | [`COALECSE`] | `COALECSE` is [`ANSI`] and supports more than two arguments, `ISNULL` has dangerous behaviour with possibility to implicit triming string | [16],[17] |
+| [`DATEDIFF`] | [`DATEADD`] | The predicate `MyDateTime < DATEADD(SECOND, -1, GETUTCDATE())` syntax is [`SARGable`] | [18],[19] |
+| [`SELECT`] | [`SET`] | Using `SET` (is [`ANSI`]) instead of `SELECT` when assigning variables due to properly work with `Msg 501 Subquery returned more than 1 value` | [20],[21],[22] |
+| [`STR`] | [`CAST`][10] | `STR` is not [`ANSI`], extremly slow, don't use more than 15 digits, and has rounding problem - use `CAST` plus concatenate instead `STR` | [23] |
+| [`ISNUMERIC`] | [`TRY_CONVERT`] | `ISNUMERIC` can often lead to data type conversion errors, when importing data. For SQL Server below 2012 use `WHERE` with `LIKE`. | [24] |
+| [`GETDATE`] | [`SYSUTCDATETIME`] | Daylight Saving Time and other factors can play havoc with our dates and times, rounding to the nearest 3 milliseconds. | [25] |
+| [`GETUTCDATE`] | [`SYSUTCDATETIME`] | Daylight Saving Time and other factors can play havoc with our dates and times, rounding to the nearest 3 milliseconds. | [25] |
+| [`SYSDATETIME`] | [`SYSUTCDATETIME`] | Daylight Saving Time and other factors can play havoc with our dates and times, rounding to the nearest 3 milliseconds. | [25] |
+| [`CURRENT_TIMESTAMP`] | [`SYSUTCDATETIME`] | It's too similar to the poorly-named TIMESTAMP data type, which has nothing to do with dates and times and should be called ROWVERSION. | [26] |
+| [`DATETIMEFROMPARTS`] | [`DATETIME2FROMPARTS`] | It's too similar to the poorly-named TIMESTAMP data type, which has nothing to do with dates and times and should be called ROWVERSION. | [26] |
+| [`ISDATE`] | [`TRY_CONVERT`] | `ISNUMERIC` can often lead to data type conversion errors, when importing data. For SQL Server below 2012 use `WHERE` with `LIKE`. | [26] |
+| [`BETWEEN`] | `>=` and `<=` | Always use an open-ended range to prevent erroneously including or excluding rows. It's much less complex to find the beginning of the next period than the end of the current period. | [27] |
 
 [12]:https://docs.microsoft.com/sql/t-sql/language-elements/comparison-operators-transact-sql
 [13]:https://dba.stackexchange.com/a/155670/107045
@@ -244,6 +245,8 @@ This is only recommendations! But it is consistent for choosing only 1 function
 [`SYSDATETIME`]:https://docs.microsoft.com/sql/t-sql/functions/sysdatetime-transact-sql
 [26]:https://bornsql.ca/blog/dates-and-times-in-sql-server-more-functions-you-should-never-use/
 [`ISDATE`]:https://docs.microsoft.com/sql/t-sql/functions/isdate-transact-sql
+[`BETWEEN`]:https://docs.microsoft.com/sql/t-sql/language-elements/between-transact-sql?view=sql-server-ver15
+[27]:https://www.mssqltips.com/sqlservertip/5206/sql-server-datetime-best-practices/
 
 **[⬆ back to top](#table-of-contents)**
 
@@ -437,7 +440,7 @@ SQL Server T-SQL Coding Conventions, Best Practices, and Programming Guidelines.
  - Avoid using `INSERT INTO` a permanent table with `ORDER BY`.
  More details [here](https://www.red-gate.com/hub/product-learning/sql-prompt/sql-prompt-code-analysis-insert-permanent-table-order-pe020).
  - Avoid using shorthand (`wk, yyyy, d` etc.) with date/time operations, use full names: `month, day, year`.
- More details [here](https://sqlblog.org/2011/09/20/bad-habits-to-kick-using-shorthand-with-date-time-operations).
+ More details [here](https://sqlblog.org/2011/09/20/bad-habits-to-kick-using-shorthand-with-date-time-operations) and [here][27].
  - Avoid ambiguous formats for date-only literals, use `CAST('yyyymmdd' AS DATE)` format.
  - Avoid treating dates like strings and avoid calculations on the left-hand side of the `WHERE` clause.
  More details [here](https://sqlblog.org/2009/10/16/bad-habits-to-kick-mis-handling-date-range-queries).