Skip to main content

Belajar PostgreSQL 18.6 untuk Newbie (Part 2): Dari Installation hingga DDL & DML dengan pgAdmin 4 Web

Bahagian 2 — Belajar PostgreSQL dengan pgAdmin 4 Web

Sekarang setup sudah selesai.

Bahagian ini lebih menarik kerana kita mula menggunakan database.


9. Membuat database testdb

Dalam pgAdmin:

Servers
└── PostgreSQL 18.6
    └── Databases

Kita membuat database:

testdb

Pada peringkat ini kita sudah mempunyai:

PostgreSQL 18.6
└── testdb

10. PostgreSQL mempunyai konsep Role

Ini antara perkara pertama yang mungkin mengelirukan pengguna MSSQL.

PostgreSQL banyak menggunakan istilah:

ROLE

Role boleh digunakan sebagai login role dan juga boleh mempunyai permission.

Untuk latihan kita, kita membuat:

testdb_app

Role ini dibenarkan login tetapi bukan superuser.

Ini sangat penting.

Kita tidak mahu aplikasi biasa menggunakan:

postgres

sebagai user database.

Sebaliknya:

postgres

digunakan sebagai administrative account.

Manakala:

testdb_app

digunakan oleh aplikasi.

Secara konsep:

postgres
    ↓
Administrator

testdb_app
    ↓
Application user

Ini dipanggil prinsip least privilege.

Berikan aplikasi hanya permission yang diperlukan.


11. Database permission

Role testdb_app perlu diberi permission untuk connect kepada database testdb.

Dalam pgAdmin:

testdb
→ Properties
→ Security

Kita memberikan:

CONNECT

kepada:

testdb_app

Dalam paparan privilege pgAdmin, huruf:

C

bermaksud:

CONNECT

12. Schema public

Di dalam database testdb, kita akan melihat:

Schemas
└── public

Ini ialah schema default yang biasa kita jumpa dalam PostgreSQL.

Di sinilah table latihan kita akan diletakkan.

Tetapi ada satu perkara penting.

Permission database dan permission schema ialah dua perkara berbeza.

Kita sudah memberikan:

CONNECT

kepada database.

Sekarang testdb_app juga memerlukan permission terhadap schema.

Kita memberikan:

USAGE

kepada public.

Dalam pgAdmin, U bermaksud:

USAGE

13. USAGE sahaja tidak cukup

Ini ialah satu perkara yang saya sendiri jumpa semasa belajar.

Selepas memberikan:

USAGE

saya cuba membuat table:

CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Tetapi PostgreSQL memberikan error:

permission denied for schema public

Kenapa?

Kerana:

USAGE

tidak bermaksud:

CREATE

Ia hanya membenarkan role menggunakan schema tersebut.

Jadi kita perlu memberikan:

CREATE

juga.

Dalam pgAdmin, permission akhirnya menjadi:

CU

iaitu:

C = CONNECT
U = USAGE

Perlu berhati-hati kerana huruf yang sama boleh muncul pada object berbeza mengikut context privilege.

Untuk schema public, kita memerlukan:

USAGE
CREATE

14. Membuat table pertama

Sekarang testdb_app mempunyai permission yang diperlukan.

Kita buka:

PostgreSQL 18.6 - testdb_app
→ testdb
→ Query Tool

Kemudian:

CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(150),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Query berjaya:

CREATE TABLE

Kemudian refresh:

Schemas
└── public
    └── Tables
        └── customers

Kita sudah mempunyai table pertama.


15. SERIAL — adakah ia datatype?

Ini merupakan salah satu perkara yang paling mengejutkan bagi pengguna MSSQL.

Kita menulis:

id SERIAL

Tetapi apabila melihat structure table dalam pgAdmin, datatype column itu ialah:

integer

Pada mulanya mungkin kita fikir:

"Bukankah saya declare SERIAL?"

Sebenarnya SERIAL bukan datatype sebenar seperti INTEGER.

Ia lebih sesuai difahami sebagai shortcut.

Secara konsep:

SERIAL
   ↓
INTEGER
   +
SEQUENCE
   +
DEFAULT nextval(...)

Sebab itu id akhirnya mempunyai datatype:

integer

tetapi nombornya meningkat secara automatik.

Saya suka menganggap SERIAL sebagai:

arahan 3-in-1


16. Perbandingan SERIAL dengan MSSQL IDENTITY

Dalam SQL Server kita biasa melihat:

id INT IDENTITY(1,1)

Secara konsep:

INT
+
IDENTITY

PostgreSQL:

id SERIAL

secara konsep menyediakan:

INTEGER
+
SEQUENCE
+
DEFAULT

Jadi jangan terkejut apabila pgAdmin menunjukkan:

integer

untuk column yang kita declare sebagai SERIAL.

PostgreSQL moden juga mempunyai:

id INTEGER GENERATED ALWAYS AS IDENTITY

yang merupakan pendekatan yang lebih moden untuk auto-generated identity columns.


17. INSERT data

Sekarang kita gunakan DML.

Kita masukkan tiga rekod:

INSERT INTO customers (name, email)
VALUES
    ('Ali', 'ali@example.com'),
    ('Siti', 'siti@example.com'),
    ('Ahmad', 'ahmad@example.com');

PostgreSQL memberikan:

INSERT 0 3

Perhatikan sesuatu yang penting.

Kita tidak memasukkan id.

Namun PostgreSQL tetap menghasilkan nombor ID secara automatik.

Hasilnya lebih kurang:

id    name     email
1     Ali      ali@example.com
2     Siti     siti@example.com
3     Ahmad    ahmad@example.com

Ini membuktikan bahawa SERIAL tadi memang menyediakan mekanisme auto-number.


18. Melihat data menggunakan GUI

Kalau sudah biasa dengan SSMS, bahagian ini sangat familiar.

Dalam pgAdmin:

customers
→ Right Click
→ View/Edit Data
→ All Rows

Kita akan nampak ketiga-tiga rekod.

Ini hampir sama dengan pengalaman:

SSMS
→ Right Click Table
→ Select Top 1000 Rows

Bezanya, pgAdmin juga membenarkan kita mengedit data secara terus melalui grid.


19. Edit data melalui pgAdmin

Contohnya kita ubah email Ali:

ali@example.com

kepada:

ali@mycompany.com

Kemudian tekan:

Save Data Changes

pgAdmin akan menjalankan operasi UPDATE kepada PostgreSQL di belakang tabir.

Secara konsep ia sama seperti:

UPDATE customers
SET email = 'ali@mycompany.com'
WHERE id = 1;

Jadi GUI hanyalah satu cara untuk berinteraksi dengan SQL database.

Ia tidak menggantikan SQL.

Ia cuma menyediakan interface yang lebih mudah.


20. DDL dan DML

Bagi pembaca yang sudah biasa dengan SQL, konsep asas DDL dan DML dalam PostgreSQL tidaklah terlalu berbeza.

DDL

Data Definition Language:

CREATE TABLE
ALTER TABLE
DROP TABLE
CREATE INDEX
CREATE VIEW

Contoh:

CREATE TABLE customers (...);

DML

Data Manipulation Language:

INSERT
UPDATE
DELETE

Dan untuk membaca data:

SELECT

Jadi seseorang yang sudah biasa dengan SQL Server tidak perlu belajar SQL dari kosong untuk menggunakan PostgreSQL.

Yang lebih penting ialah memahami perbezaan behaviour dan database architecture antara kedua-duanya.


21. Apa yang saya pelajari daripada latihan ini?

Selepas latihan ini, kita sudah membina keseluruhan flow:

Ubuntu Server
      │
      ▼
PostgreSQL 18.6
      │
      ▼
Database: testdb
      │
      ▼
Role: testdb_app
      │
      ├── CONNECT
      │
      ▼
Schema: public
      │
      ├── USAGE
      └── CREATE
      │
      ▼
Table: customers
      │
      ├── id
      ├── name
      ├── email
      └── created_at
      │
      ▼
INSERT / UPDATE
      │
      ▼
View/Edit Data melalui pgAdmin

Ini sudah merupakan asas yang cukup baik untuk mula membina aplikasi sebenar.


22. Perkara yang paling penting untuk newbie MSSQL

Jika anda datang daripada Microsoft SQL Server, jangan cuba memaksa semua konsep PostgreSQL supaya kelihatan sama dengan MSSQL.

Sebaliknya, gunakan MSSQL sebagai titik perbandingan.

Contohnya:

MSSQL                    PostgreSQL
------------------------------------------------
SSMS                     pgAdmin
Login/User               Role
INT                      INTEGER
IDENTITY                 IDENTITY / SERIAL
Database                 Database
Schema                   Schema
GRANT                    GRANT
DENY                     GRANT/REVOKE model
dbo                      Tidak ada konsep yang sama tepat

Ada persamaan, tetapi ada juga perbezaan architecture yang penting.


Kesimpulan

Belajar PostgreSQL tidak semestinya bermula dengan perkara yang complicated.

Untuk newbie, saya rasa lebih baik bermula dengan satu flow yang lengkap:

Install
   ↓
Configure
   ↓
Secure connection
   ↓
Install pgAdmin
   ↓
Connect pgAdmin
   ↓
Create database
   ↓
Create role
   ↓
Grant permission
   ↓
Create table
   ↓
INSERT
   ↓
View/Edit Data

Selepas semua ini berjaya, barulah masuk kepada topik yang lebih mendalam seperti:

  • ROLE dan ownership
  • schema management
  • GRANT dan REVOKE
  • SEARCH_PATH
  • sequences
  • IDENTITY
  • foreign keys
  • indexes
  • transactions
  • EXPLAIN
  • backup/restore
  • PostgreSQL performance
  • connection pooling
  • penggunaan PostgreSQL daripada aplikasi

Bagi saya, bahagian paling menarik daripada pengalaman ini ialah menyedari bahawa PostgreSQL bukanlah "SQL Server versi Linux".

Ia mempunyai konsepnya sendiri.

Tetapi jika anda sudah biasa dengan MSSQL, asas SQL yang anda sudah tahu sebenarnya memberikan kelebihan yang besar. Anda cuma perlu belajar bagaimana PostgreSQL melakukan sesuatu dengan cara yang sedikit berbeza.

Dan kadang-kadang perbezaan itu boleh menghasilkan kejutan kecil — contohnya:

Declare SERIAL, tetapi pgAdmin tunjuk integer. 😄

Rupanya SERIAL bukan datatype baru pun.

Ia cuma shortcut 3-in-1.

Dan dari situlah pembelajaran PostgreSQL bermula.

Comments

Popular posts from this blog

Siri Vibe Coding S01E03: FreeLLMAPI: 16 Otak, 1 Pintu Rev. #2

Ini artikel KETIGA dalam siri Vibe Coding saya. Kalau belum baca Artikel 1 (VSCode + Cline + MCP + MSSQL) dan Artikel 2 (Local AI Ollama), sila baca dulu. Dalam artikel ni, kita tambah SATU lagi "otak" untuk Cline — kali ni bukan local, tapi gabungan pelbagai AI cloud percuma dalam satu tempat. 😄 Nota jenaka : Macam artikel-artikel lepas, saya selit jenaka sikit-sikit. Kalau tak kena selera, skip terus ke arahan teknikal. Yang penting duit awak selamat (percuma je pun), bukan lawak saya kena. 📑 Kandungan (Table of Content) Kenapa Perlu FreeLLMAPI? Bahagian 1: Prasyarat — Install Docker Desktop Bahagian 2: Install FreeLLMAPI (Guna Port 11500) Bahagian 3: Urus Akaun Provider — Contoh Lengkap dengan Groq Bahagian 4: Guna FreeLLMAPI Secara Standalone Bahagian 5: Sambungkan ke Open WebUI Bahagian 6: Sambungkan ke Jan.ai Bahagian 7: Sambungkan ke VSCode + Cline Bahagian 8: Ujian Bahagian 9: Bacaan Lanjut Penutup Kenapa Perlu FreeLLMAPI? Dalam Artikel 2, kita setup l...

Siri Vibe Coding S01E01: Panduan Lengkap: VSCode + Cline: Cinta Pandang Pertama (Zero to Hero) Rev.#2

Panduan ini ditulis untuk sesiapa yang baru nak mula "vibe coding" — iaitu menulis kod dengan bantuan AI agent yang boleh terus edit fail, jalankan command, dan sambung ke database. Tak perlu pengalaman VSCode sebelum ni. Ikut je step demi step. 📸 Nota pasal screenshot dalam panduan ni : Setiap bahagian penting ada penanda 📸 [AMBIL SCREENSHOT DI SINI] — ambil gambar skrin awak SENDIRI di titik tu semasa ikut langkah, dan sisipkan dalam blog post awak. Ini lebih baik dari guna gambar orang lain — versi UI awak akan tepat sama dengan apa pembaca nampak di skrin mereka, dan awak elak isu hak cipta guna gambar orang lain. 😄 Amaran kecil : Panduan ni panjang — bukan sebab saya "tak reti" ringkaskan, tapi sebab vibe coding ni ada BANYAK moving parts (editor, AI, database, semua kena "kenal" antara satu sama lain). Saya selit sikit jenaka sepanjang jalan supaya mata tak "freeze" macam program yang hang. Kalau jenaka tak sampai, skip terus ke ara...

AI Tools 12 For Marketing

 AI Tools 12 For Marketing