# Diskusi Arsitektur Database & Solusi Storage ERP

**Tanggal Diskusi:** [Otomatis tersimpan]
**Topik:** Evaluasi struktur database, penanganan isu *storage* membengkak, dan strategi implementasi "Tutup Buku" (Cut-Off) pada ERP skala besar (50+ modul).

---

## 1. Perbandingan Konteks Database Saat Ini

Terdapat dua pendekatan database yang dianalisis:

*   **`san_30mar` (Pendekatan Monolithic):**
    *   Terdapat satu tabel raksasa global bernama `transaksi_data_registry`.
    *   Sangat besar dan gemuk (sekitar 60 kolom, mayoritas bertipe `longblob`).
    *   Menampung seluruh data transaksi dari 50+ modul yang ada di ERP.
*   **`san_tsa_28agu` (Pendekatan Modular / Domain-Driven):**
    *   Tabel dipecah berdasarkan domain modul (contoh: `pembelian_transaksi_data_registry`).
    *   Sangat ramping (hanya sekitar 11 kolom).
    *   Menyimpan data *registry* spesifik per divisi/modul.

> [!TIP]
> **Menurut ISO 25010 & Best Practice Software Engineering:** Arsitektur modular (`san_tsa_28agu`) jauh lebih unggul karena menyelesaikan masalah *lock contention* (antrean baca/tulis), mempermudah pemeliharaan, dan memisahkan keamanan data antar divisi (*Bounded Context*).

---

## 2. Masalah Utama: Storage Membengkak

Memigrasikan struktur database dari model Monolithic (`san_30mar`) menjadi Modular (`san_tsa_28agu`) untuk 50+ modul secara bersamaan **sangat berisiko dan memakan waktu 6-12 bulan**. Pendekatan ini (membongkar kode 50 modul) tidak disarankan jika target utama jangka pendeknya hanyalah mengatasi *storage* yang penuh.

## 3. Solusi Utama: Database Cut-Off (Tutup Buku)

Solusi paling aman, cepat, dan efektif untuk membebaskan ruang *storage* **tanpa perlu merombak satu baris pun kode PHP CodeIgniter** adalah dengan metode **Cut-Off Database** (seperti membuat `san_1jan26`).

### Cara Kerja:
1.  **Hitung & Identifikasi:** Menarik data Saldo Akhir dan transaksi yang masih gantung (belum lunas/belum dikirim) dari `san_30mar`.
2.  **Pembuatan Database Baru:** Membuat database baru yang kosong dan bersih (`san_1jan26`).
3.  **Injeksi Saldo Awal:** Memasukkan transaksi gantung tersebut ke database baru sebagai Saldo Awal (*Starting Balance*).
4.  **Peralihan (Cut-Over):** Mengubah koneksi di `application/config/database.php` ke database baru. Database lama diarsip/kompres.

### Estimasi Waktu (Untuk 50+ Modul):
*   **Total Waktu: 1 hingga 2 Bulan.**
*   *Catatan:* Waktu terlama **bukan** dihabiskan untuk *koding*, melainkan untuk rapat koordinasi, pengecekan, dan validasi Saldo Awal dengan 50+ perwakilan divisi (Gudang, Keuangan, HR, dll) agar data 100% akurat sebelum eksekusi (*Dry Run*).

---

## 4. Analisis Usulan Penambahan Kolom Status (`is_active`)

**Usulan:** Menambahkan kolom penanda *active/inactive* langsung ke tabel `san_30mar.transaksi_data_registry` untuk menghindari pencarian/observasi manual saat proses *Cut-Off*.

> [!WARNING]
> **Risiko Teknis Tinggi (Hambatan):**
> 1. **Downtime Ekstrem:** Mengeksekusi query `ALTER TABLE ADD COLUMN` pada tabel berukuran ratusan Gigabyte yang penuh dengan `longblob` dapat mengunci tabel selama berjam-jam, membuat ERP lumpuh total.
> 2. **Menghanguskan Keuntungan "Tanpa Koding":** Jika kolom baru dibuat, Anda wajib membongkar dan merombak logika pemrograman (*source code* PHP) di seluruh 50+ modul agar aplikasi secara disiplin memperbarui (update) nilai status di kolom tersebut setiap kali transaksi selesai. 
> 3. **Backfill Data Lama:** Tetap diperlukan *script* masal satu kali untuk mendata dan mengisi status `is_active` pada jutaan transaksi historis masa lalu yang sudah telanjur tersimpan.

> [!TIP]
> **Alternatif Terbaik:**
> Alih-alih membuat kolom fisik baru, *Database Engineer* disarankan membuat **Database View** (tabel virtual) di level MySQL. *View* ini dirancang untuk memfilter otomatis transaksi mana yang masih gantung (berdasarkan flag atau status bawaan yang sudah eksis di masing-masing modul) tanpa menyentuh struktur tabel asli maupun kode aplikasi.