feat: add more recommendations (DA-2038,DA-2040,DA-2051,DA-2035)

content/700-optimize/300-recordings.mdx

@@ -42,6 +42,9 @@ When a recording session ends, Optimize generates recommendations such as:
 - [Repeated query](/optimize/recommendations/repeated-query)
 - [Overfetching](/optimize/recommendations/select-returning)
 - [Using `@db.Money`](/optimize/recommendations/avoid-db-money)
+- [Using `@db.Char(n)`](/optimize/recommendations/avoid-char)
+- [Using `@db.VarChar(n)`](/optimize/recommendations/avoid-varchar)
+- [Using `@db.Timestamp(0)` and `@db.Timestamptz(0)`](/optimize/recommendations/avoid-timestamp-timestamptz-0)
 
 :::info
 Use [Prisma AI](/optimize/prisma-ai) to ask follow-up questions about a recommendation.

content/700-optimize/400-recommendations/600-avoid-db-money.mdx

@@ -6,7 +6,7 @@ tocDepth: 3
 toc: true
 ---
 
-Optimize provides recommendations to help you identify and resolve performance issues caused by the use of `@db.Money` type.
+Optimize provides recommendations to help you identify and resolve performance issues caused by the use of `@db.Money` type in PostgreSQL.
 
 The following model uses the `@db.Money` native type:
 

content/700-optimize/400-recommendations/700-avoid-char.mdx

@@ -0,0 +1,23 @@
+---
+title: 'Using @db.Char(n)'
+metaTitle: 'Optimize Recommendations: Avoid usage of `@db.Char(x)`'
+metaDescription: "Learn about the recommendation provided by Optimize for using `@db.Char(x)` native type."
+tocDepth: 3
+toc: true
+---
+
+Optimize provides recommendations to help you identify and resolve performance issues caused by the use of `@db.Char(n)` type in PostgreSQL.
+
+The `@db.Char(n)` native type has been used within the `Item` model on the name field:
+
+```prisma
+model Item {
+  // ...
+  name String @db.Char(1)
+  // ...
+}
+```
+
+### Why this is a problem
+
+The `@db.Char(n)` type enforces a fixed length of `n`, which can cause unexpected issues in production if not properly managed by the application. In PostgreSQL, `char(n)` pads shorter values with spaces, leading to problems during comparisons and other operations. Unlike some databases that optimize `char(n)`, PostgreSQL does not offer such optimizations, making careful handling essential.

content/700-optimize/400-recommendations/800-avoid-varchar.mdx

@@ -0,0 +1,23 @@
+---
+title: 'Using @db.VarChar(n)'
+metaTitle: 'Optimize Recommendations: Avoid usage of `@db.VarChar(x)`'
+metaDescription: "Learn about the recommendation provided by Optimize for using `@db.Char(x)` native type."
+tocDepth: 3
+toc: true
+---
+
+Optimize provides recommendations to help you identify and resolve performance issues caused by the use of `@db.VarChar(n)` type in PostgreSQL.
+
+The `@db.VarChar(n)` native type has been used within the `Item` model on the name field:
+
+```prisma
+model Item {
+  // ...
+  name String @db.VarChar(1)
+  // ...
+}
+```
+
+### Why this is a problem
+
+The `@db.VarChar(n)` type restricts content to a maximum length of `n`, which can cause unexpected issues in production if not properly managed by the application. In PostgreSQL, `varchar(n)` performs the same as `text`, and no additional optimizations are provided for `varchar(n)`, making the choice between them more about convention than performance.

content/700-optimize/400-recommendations/900-avoid-timestamp-timestamptz-0.mdx

@@ -0,0 +1,26 @@
+---
+title: 'Using timestamp(0) or timestamptz(0)'
+metaTitle: 'Optimize Recommendations: Avoid usage of `timestamp(0)` or `timestamptz(0)`'
+metaDescription: "Learn about the recommendation provided by Optimize for using `timestamp(0)` or `timestamptz(0)` native type."
+tocDepth: 3
+toc: true
+---
+
+Optimize provides recommendations to help you identify and resolve performance issues caused by the use of `@db.Timestamp(0)` and `@db.Timestamptz(0)` native types in PostgreSQL.
+
+The `@db.Timestamp(0)` and `@db.Timestamptz(0)` native types have been used within the following `User` model:
+
+```prisma
+model User {
+  // ...
+  date DateTime @db.Timestamp(0)
+  deletedAt DateTime @db.Timestamptz(0)
+  // ...
+}
+```
+
+### Why this is a problem
+
+When using a `@db.Timestamp(n)` or `@db.Timestamptz(n)` column with a precision of `0`, the database rounds the time to the nearest whole second, which can lead to unexpected results. 
+
+For example, if you insert the current time, such as `15:30:45.678`, into a column with this precision, it will round up to `15:30:46`. This behavior can cause the recorded time to appear up to half a second in the future compared to the original time, which may be surprising when precise time accuracy is critical.