adeindriawan
commented
2 years ago Problem: User yang berganti departemen/unit. Bagaimana memastikan data order tetap konsisten dengan data user dan data departemen/unit.
Kondisi eksisting:
Data order hanya berelasi dengan data user (jawaban poin ke-2). Di sistem yang lama, belum ada alur yang fix jika ada user yang pindah departemen/unit. Pernah ada user yang pindah departemen/unit kemudian hanya berganti ID unitnya saja, tapi pernah juga ada user yang pindah departemen/unit kemudian membuat data user baru dengan ID user & ID unit yang berbeda.
Usulan solusi:
- Membuat user baru,
- Menambah primary key departemen ID pada data order,
Coba kita brainstorming sedikit:
- Di sistem yang baru ini, usulan solusi yang paling mudah diimplementasikan adalah solusi no 1, membuat data user baru ketika user tersebut berpindah unit, karena tidak mengubah skema database yang sudah ada,
- Aku belum menemukan keuntungan kalau kita melakukan solusi 2, menambahkan primary key gabungan antara user dan departemen di data order,
- Jika mau mengambil data histori pemesanan user antar departemen/unit tanpa kehilangan integritas data, maka cukup terapkan solusi 1, jadi ketika user berpindah departemen/unit, kita buat data user baru, jadi data order dengan user yang lama kita freeze, karena user baru dengan departemen/unit yang baru sudah memiliki user ID baru (namun tetap dengan email yang sama). Kalau kita mau lihat histori order user antar departemen/unit, maka kita cukup data histori order yang dipesan oleh user dengan email yang sama yang dipegang, maka bisa terlihat data histori order dari satu unit ke unit lain.
Gitu menurutku, gimana pendapatmu?
Problem:
Harusnya order mempunyai primary key gabungan antara user dan departemen. dua user dengan email sama dan orang yang sama tapi berbeda unit dianggap sebagai dua user yang berbeda. Harus ada prosedur saat user berganti departemen. sehingga pesanan user di departemen sebelumnya dipisahkan dengan pesanan user di departemen yang ditempati sekarang.