Foto oleh panumas nikhomkhai via Pexels

Memilih tipe data yang tepat saat mendesain table bukan sekadar formalitas administratif — keputusan ini memengaruhi ukuran penyimpanan, performa query, dan integritas data dalam jangka panjang. Kesalahan memilih tipe data, terutama untuk uang dan teks, sering baru terasa dampaknya setelah aplikasi berjalan lama dan sulit diperbaiki tanpa migrasi data besar-besaran yang berisiko terhadap data produksi.

Artikel ini membahas tipe data yang paling umum dipakai di SQL Server, disertai perbandingan konkret kapan masing-masing cocok digunakan dan jebakan yang sering terjadi akibat pilihan yang keliru sejak awal desain.

Tipe Data Angka

DECIMAL untuk harga, bukan FLOAT

CREATE TABLE Products ( ProductId INT PRIMARY KEY IDENTITY, Price DECIMAL(10,2) NOT NULL, StockQty INT NOT NULL ); INSERT INTO Products (Price, StockQty) VALUES (15000.50, 100); SELECT Price * 1.11 AS HargaSetelahPpn FROM Products; -- Expected output: 16650.555 dibulatkan sesuai presisi DECIMAL(10,2) -> 16650.56
  • int — bilangan bulat 32-bit, cocok untuk ID dan penghitung, rentang hingga sekitar 2 miliar
  • bigint — dipakai jika int diperkirakan tidak cukup, misalnya ID pada tabel dengan miliaran baris
  • decimal(p,s) — wajib dipakai untuk nilai uang karena presisinya pasti, hindari float untuk uang karena rawan pembulatan

Parameter p pada DECIMAL menentukan total digit yang bisa disimpan, sementara s menentukan berapa digit di antaranya berada di belakang koma. DECIMAL(10,2) misalnya bisa menyimpan hingga 8 digit di depan koma dan 2 digit di belakang koma, cukup untuk kebanyakan kebutuhan harga produk.

Tipe Data Teks

  • varchar(n) — teks dengan panjang bervariasi, hanya mendukung karakter non-Unicode
  • nvarchar(n) — sama seperti varchar tapi mendukung Unicode (emoji, huruf non-Latin), disarankan untuk nama dan input pengguna
  • char(n) — panjang tetap, cocok untuk data berukuran pasti seperti kode pos atau kode negara dua huruf

varchar berisiko merusak karakter non-ASCII

DECLARE @nama VARCHAR(50) = 'José García'; SELECT @nama AS HasilVarchar; -- Expected output: José García bisa berubah jadi 'Jos? Garc?a' -- karena varchar tidak mendukung karakter beraksen tertentu -- tergantung collation server

Masalah ini sering baru terlihat ketika aplikasi mulai melayani pengguna dari negara lain atau menerima input berisi emoji, dan harus diperbaiki dengan ALTER COLUMN mengubah tipe data ke NVARCHAR — operasi yang bisa memakan waktu lama pada tabel besar.

Tipe Data Tanggal dan Waktu

DATETIME2 lebih presisi dibanding DATETIME lama

CREATE TABLE Orders ( OrderId INT PRIMARY KEY IDENTITY, OrderDate DATETIME2 DEFAULT SYSDATETIME(), ShippedDate DATE NULL ); INSERT INTO Orders DEFAULT VALUES; SELECT OrderDate FROM Orders; -- Expected output: 2026-10-03 14:22:10.1234567 (presisi hingga 100 nanodetik)

DATETIME2 direkomendasikan Microsoft dibanding DATETIME karena presisi lebih tinggi dan rentang tanggal lebih luas (dari tahun 0001 dibanding 1753 pada DATETIME lama), sementara DATE dipakai jika jam tidak relevan, seperti tanggal lahir pelanggan yang tidak memerlukan informasi waktu sama sekali.

Perbandingan VARCHAR, NVARCHAR, dan Dampaknya pada Penyimpanan

Perbedaan ukuran penyimpanan VARCHAR vs NVARCHAR

-- VARCHAR menyimpan 1 byte per karakter (karakter Latin) CREATE TABLE Produk ( NamaProduk VARCHAR(100), Deskripsi NVARCHAR(500) ); -- Mengecek ukuran penyimpanan aktual sebuah nilai string SELECT DATALENGTH(N'Kemeja Lengan Panjang') AS NVarcharBytes, DATALENGTH('Kemeja Lengan Panjang') AS VarcharBytes; -- Hasil: NVarcharBytes = 44, VarcharBytes = 22

VARCHAR menyimpan setiap karakter menggunakan 1 byte dan cocok untuk data yang dipastikan hanya berisi karakter Latin standar, sedangkan NVARCHAR menyimpan setiap karakter menggunakan 2 byte menggunakan encoding UTF-16 sehingga mampu menampung karakter dari berbagai bahasa termasuk aksara Arab, Mandarin, maupun emoji. Konsekuensinya, kolom NVARCHAR memakan ruang penyimpanan dua kali lebih besar dibanding VARCHAR untuk panjang karakter yang sama.

Pemilihan antara keduanya sebaiknya didasarkan pada kebutuhan nyata aplikasi: sistem yang hanya beroperasi dalam satu bahasa dengan alfabet Latin seperti nama produk berbahasa Indonesia tanpa karakter khusus masih bisa memakai VARCHAR dengan aman, namun aplikasi yang perlu mendukung input multi-bahasa atau nama pelanggan internasional sebaiknya memakai NVARCHAR sejak awal, karena mengubah tipe data di kemudian hari pada table yang sudah berisi jutaan baris bisa memakan waktu lama dan berisiko.

Satu kesalahan umum adalah menulis literal string untuk kolom NVARCHAR tanpa awalan huruf N, misalnya WHERE Nama = 'Budi' alih-alih WHERE Nama = N'Budi'; tanpa awalan N, SQL Server akan memperlakukan literal tersebut sebagai VARCHAR terlebih dahulu sehingga bisa memicu implicit conversion yang membuat index pada kolom tersebut tidak terpakai secara optimal.

Tipe Data Tanggal dan Waktu: DATE, DATETIME, DATETIME2, dan Presisinya

Membandingkan presisi dan ukuran penyimpanan tipe tanggal

-- Membandingkan rentang nilai dan presisi beberapa tipe tanggal/waktu DECLARE @d1 DATE = '2026-10-03'; DECLARE @d2 DATETIME = '2026-10-03 14:30:00.123'; DECLARE @d3 DATETIME2(3) = '2026-10-03 14:30:00.1234567'; SELECT @d1 AS KolomDate, @d2 AS KolomDatetime, @d3 AS KolomDatetime2, DATALENGTH(@d1) AS UkuranDate, DATALENGTH(@d2) AS UkuranDatetime, DATALENGTH(@d3) AS UkuranDatetime2; -- Hasil: -- KolomDate: 2026-10-03 -- KolomDatetime: 2026-10-03 14:30:00.123 -- KolomDatetime2: 2026-10-03 14:30:00.123 -- UkuranDate: 3, UkuranDatetime: 8, UkuranDatetime2: 5

SQL Server menyediakan beberapa tipe data untuk menyimpan tanggal dan waktu, masing-masing dengan rentang nilai, presisi, dan ukuran penyimpanan yang berbeda. DATE hanya menyimpan tanggal tanpa komponen waktu dan memakai 3 byte, cocok untuk kolom seperti tanggal lahir atau tanggal jatuh tempo yang tidak memerlukan jam. DATETIME menyimpan tanggal dan waktu dengan presisi sepertiga detik (dibulatkan ke kelipatan .000, .003, atau .007) dan rentang terbatas mulai tahun 1753.

DATETIME2 merupakan tipe yang lebih modern dengan presisi dapat dikonfigurasi dari 0 hingga 7 digit desimal detik, rentang tanggal yang jauh lebih luas mulai tahun 0001, dan ukuran penyimpanan yang justru bisa lebih hemat dibanding DATETIME jika presisi yang diminta rendah, misalnya DATETIME2(0) hanya memakai 6 byte. Microsoft secara eksplisit merekomendasikan DATETIME2 untuk pengembangan baru dan menganggap DATETIME sebagai tipe lama yang dipertahankan untuk kompatibilitas.

Kesalahan umum adalah memakai DATETIME untuk kolom yang sebenarnya hanya butuh tanggal, yang memboroskan ruang penyimpanan dan memori buffer pool tanpa manfaat, atau sebaliknya memakai DATETIME2 dengan presisi tinggi seperti DATETIME2(7) padahal aplikasi tidak pernah membutuhkan presisi hingga seratus nanodetik. Pemilihan presisi yang tepat sejak desain table berdampak langsung pada ukuran table, kecepatan backup, dan efisiensi indeks yang melibatkan kolom tanggal, terutama pada table dengan jutaan baris yang bertambah setiap hari.

Memilih Presisi DECIMAL yang Tepat untuk Data Uang

Perbandingan DECIMAL dan FLOAT

-- DECIMAL menyimpan angka eksak, FLOAT menyimpan angka perkiraan DECLARE @HargaDecimal DECIMAL(10,2) = 19.90; DECLARE @HargaFloat FLOAT = 19.90; SELECT @HargaDecimal * 3 AS TotalDecimal, @HargaFloat * 3 AS TotalFloat; -- Hasil: -- TotalDecimal: 59.70 (tepat) -- TotalFloat: 59.700000000000003 (potensi pembulatan)

DECIMAL (sama dengan NUMERIC) menyimpan angka secara eksak berdasarkan jumlah digit presisi dan skala yang ditentukan, misalnya DECIMAL(10,2) berarti maksimal 10 digit total dengan 2 digit di belakang koma, sehingga hasil perhitungan selalu tepat tanpa pembulatan tak terduga. FLOAT sebaliknya menyimpan angka dalam bentuk pendekatan biner, yang pada operasi aritmatika berulang dapat menghasilkan selisih kecil akibat pembulatan floating point.

Untuk data yang berkaitan dengan nilai uang seperti harga, gaji, atau saldo transaksi, DECIMAL selalu menjadi pilihan yang tepat karena kesalahan pembulatan sekecil apa pun bisa berakumulasi menjadi selisih signifikan pada laporan keuangan. FLOAT lebih cocok dipakai untuk data ilmiah atau statistik yang secara alami sudah bersifat perkiraan dan tidak memerlukan presisi eksak hingga digit terakhir.

Kesalahan Umum yang Sering Terjadi

Memakai FLOAT untuk menyimpan nilai uang

FLOAT menyimpan angka dalam representasi biner yang rawan pembulatan tidak presisi, sehingga total transaksi bisa selisih beberapa sen setelah kalkulasi berulang. Selalu gunakan DECIMAL untuk nilai finansial apa pun bentuknya.

Memakai VARCHAR untuk nama yang mungkin mengandung karakter non-Latin

Nama pelanggan internasional atau emoji pada input pengguna bisa rusak/terpotong jika disimpan di VARCHAR biasa karena tidak mendukung Unicode penuh, menghasilkan data yang terlihat 'rusak' di laporan.

Mengatur panjang NVARCHAR terlalu kecil tanpa mempertimbangkan masa depan

Kolom seperti alamat email yang dibatasi terlalu pendek (misalnya 30 karakter) bisa gagal menampung alamat email modern yang cukup panjang, menyebabkan error insert di produksi yang baru terdeteksi saat sudah live.

Kapan Pendekatan Ini Tidak Cocok Dipakai

Memakai NVARCHAR untuk semua kolom teks demi 'keamanan' terdengar praktis, namun NVARCHAR memakai 2 byte per karakter dibanding VARCHAR yang hanya 1 byte, sehingga pada tabel dengan jutaan baris dan kolom teks panjang, perbedaan ini bisa berdampak signifikan pada ukuran database dan kecepatan I/O saat membaca data dalam jumlah besar.

Pilih VARCHAR jika benar-benar yakin data yang disimpan tidak akan pernah mengandung karakter non-Latin, misalnya kode internal sistem yang dibuat sendiri dengan format tetap, dan simpan NVARCHAR khusus untuk data yang berasal dari input pengguna bebas seperti nama, alamat, atau komentar yang berpotensi memakai bahasa apa pun.

Ringkasan

Memilih tipe data yang tepat sejak awal desain table akan menghemat ruang penyimpanan dan mencegah bug yang sulit dilacak, terutama terkait pembulatan angka desimal untuk uang dan dukungan karakter Unicode untuk data internasional.

Keputusan tipe data yang dibuat di awal project akan terus memengaruhi seluruh siklus hidup aplikasi, sehingga layak diberi perhatian ekstra sebelum table benar-benar dipakai menyimpan data produksi dalam jumlah besar.

Seri Belajar SQL Server:

← Sebelumnya: Mengenal Database dan Table pada SQL Server

→ Selanjutnya: Dasar Query SELECT pada SQL Server