SQL Data Types Mastery

Choosing the wrong data type is a "Silent Performance Killer." If you use NVARCHAR(MAX) for a Gender column, you are wasting massive amounts of RAM and Disk Space, and slowing down every index on that table.

1. The Text Battle: CHAR vs VARCHAR vs NVARCHAR

• CHAR(n): Fixed length. If you store 'Hi' in CHAR(10), it still takes 10 bytes (uses padding). Good for fixed IDs like ISO Country Codes (US, IN, UK).
• VARCHAR(n): Variable length. Only takes the space of the actual text. Better for Names and Descriptions.
• NVARCHAR(n): Unicode (2 bytes per character). Essential for multi-language support (Hindi, Chinese, Arabic).

2. Number Precision: INT vs BIGINT vs DECIMAL

Don't use BIGINT (8 bytes) if INT (4 bytes, up to 2.1 billion) is enough. For money, NEVER use FLOAT (approximate). Always use DECIMAL(18,2) to ensure exact mathematical precision.

3. GUIDs (The Performance Trap)

A UNIQUEIDENTIFIER is 16 bytes. While great for distributed systems, using a GUID as a **Clustered Index** causes "Index Fragmentation" because GUIDs are random. New rows are inserted in the middle of the table, forcing SQL Server to split pages and slow down your entire app.

4. Interview Mastery

Q: "What is the 'Implicit Conversion' problem in SQL Server?"

Architect Answer: "It happens when you compare two different types, e.g., `WHERE UserID = '5'` when UserID is an INT. SQL Server must convert every single row's ID to a string to do the comparison. This prevents the engine from using any existing **Indices** (Index Scan vs Index Seek), turning a 1ms query into a 10-second table scan. Always ensure your C# parameter types match your SQL column types exactly."