> For the complete documentation index, see [llms.txt](https://learn.devlabss.my.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.devlabss.my.id/laravel/bab-11-logika-transaksi-peminjaman/11.4-penjelasan-manipulasi-dua-tabel.md).

# 11.4 Penjelasan Manipulasi Dua Tabel

## Penjelasan manipulasi dua tabel

Sekarang kita rapikan logika yang tadi sudah dipraktikkan.

Pada proses peminjaman, satu klik dari pengguna bisa memengaruhi dua tabel sekaligus.

Ini adalah inti penting dari BAB 11.

### Dua tabel yang bergerak bersamaan

Saat user meminjam buku, sistem melakukan dua pekerjaan:

* menambah data baru ke tabel `peminjaman`
* mengubah nilai `stok` pada tabel `buku`

Kalau ditulis singkat:

```
insert ke peminjaman
update ke buku
```

Inilah alasan proses ini terasa lebih kompleks daripada CRUD biasa.

### Kenapa harus dua tabel

Karena dua tabel ini punya peran yang berbeda.

Tabel `peminjaman` berfungsi sebagai **riwayat transaksi**.

Tabel `buku` berfungsi sebagai **data master buku**.

Kalau Anda hanya mengubah tabel `buku`, riwayat siapa yang meminjam tidak tercatat.

Kalau Anda hanya mengisi tabel `peminjaman`, stok buku tidak ikut berubah.

Jadi dua-duanya wajib bergerak bersama.

### Urutan proses yang masuk akal

Agar hasilnya aman, urutan logikanya harus jelas:

{% stepper %}
{% step %}

### Ambil data buku

Sistem mencari buku berdasarkan ID yang dikirim.

Kalau buku tidak ditemukan, proses langsung gagal.
{% endstep %}

{% step %}

### Validasi stok

Sistem mengecek apakah stok masih tersedia.

Kalau stok `0`, transaksi tidak boleh lanjut.
{% endstep %}

{% step %}

### Simpan riwayat peminjaman

Setelah lolos validasi, data transaksi dicatat ke tabel `peminjaman`.

Di sinilah sistem menyimpan siapa meminjam buku apa.
{% endstep %}

{% step %}

### Kurangi stok buku

Setelah riwayat tercatat, sistem memperbarui stok di tabel `buku`.

Nilainya berkurang sesuai jumlah pinjaman.
{% endstep %}
{% endstepper %}

### Kenapa urutan ini penting

Bayangkan Anda mengurangi stok lebih dulu, lalu penyimpanan peminjaman gagal.

Hasilnya jadi aneh.

Stok berkurang, tetapi tidak ada riwayat transaksi.

Sebaliknya, kalau peminjaman tersimpan tetapi stok gagal diubah, sistem akan membaca jumlah stok yang salah.

Kedua kondisi ini sama-sama merusak konsistensi data.

{% hint style="warning" %}
Saat satu proses menyentuh lebih dari satu tabel, Anda harus mulai peduli pada konsistensi data. Jangan menulis urutan logika secara asal.
{% endhint %}

### Bentuk logika yang sudah Anda pakai

Secara konsep, method Anda tadi bekerja seperti ini:

```php
$buku = Buku::findOrFail($id);

if ($buku->stok < 1) {
    return redirect()->back();
}

Peminjaman::create([
    'user_id' => Auth::id(),
    'buku_id' => $buku->id,
    'tanggal_pinjam' => now()->toDateString(),
]);

$buku->decrement('stok');
```

Kode ini cukup bagus untuk memahami dasar proses bisnis.

Karena Anda bisa melihat dengan jelas:

* data dibaca dari tabel `buku`
* data baru masuk ke tabel `peminjaman`
* data lama di tabel `buku` ikut diperbarui

### Bonus pemahaman: kenalan dengan transaction database

Kalau nanti aplikasi makin serius, proses seperti ini biasanya dibungkus dengan transaction database.

Tujuannya agar semua langkah berhasil bersama.

Kalau satu langkah gagal, perubahan lain bisa dibatalkan.

<details>

<summary>Contoh versi yang lebih aman dengan transaction database</summary>

```php
use Illuminate\Support\Facades\DB;

DB::transaction(function () use ($buku) {
    Peminjaman::create([
        'user_id' => Auth::id(),
        'buku_id' => $buku->id,
        'tanggal_pinjam' => now()->toDateString(),
    ]);

    $buku->decrement('stok');
});
```

Untuk tahap dasar, Anda belum wajib menghafal ini.

Tetapi penting untuk tahu bahwa Laravel punya fitur seperti ini.

</details>

### Cara mengecek hasil manipulasi dua tabel

Setelah peminjaman berhasil, cek dua hal:

* tabel `peminjaman` bertambah satu baris
* nilai `stok` pada buku terkait berkurang

Kalau hanya salah satu yang berubah, berarti logikanya belum sinkron.

### Poin evaluasi bab 11.4

Pastikan Anda sudah memahami hal berikut:

* kenapa peminjaman menyentuh dua tabel
* kenapa riwayat transaksi dan data master harus dipisah
* kenapa urutan proses memengaruhi konsistensi data
* kapan transaction database mulai terasa penting

Jika semuanya sudah rapi, lanjut ke [11.5 Checkpoint: Uji Pemahamanmu Sebelum Lanjut!](/laravel/bab-11-logika-transaksi-peminjaman/11.5-checkpoint-uji-pemahamanmu-sebelum-lanjut.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://learn.devlabss.my.id/laravel/bab-11-logika-transaksi-peminjaman/11.4-penjelasan-manipulasi-dua-tabel.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.