Sebelum beralih ke skema dan tabel, saya ingin berbagi apa yang ingin saya capai terlebih dahulu. Saya sedang mengerjakan semacam aplikasi kurir, di mana saya memiliki beberapa categories
dan setiap kategori memiliki price
yang telah ditentukan sebelumnya.
Tapi, menentukan harga agak jelek (tidak ada simetri dan pola; setidaknya, saya tidak bisa menemukannya). Saya akan memberi Anda sebuah contoh:
Pertimbangkan kategori berikut: Dokumen, Dokumen Berat, Laptop, Karton, Karton Berat.
1) Dokumen: Ini untuk dokumen yang lebih ringan, yaitu di bawah 0,5kg. Harganya $20, tetap.
[harga yang tersimpan di tabel harga: 20.00]
misalnya Untuk item seberat 300g, harganya menjadi $20.
2) Dokumen Berat: Ini untuk dokumen yang beratnya lebih dari 0,5kg. Berbeda dengan kategori Dokumen, tidak memiliki harga tetap! Sebaliknya, ini memiliki harga satuan: $10 per kg, yang akan diterapkan pada setiap kg kecuali/setelah 0,5kg.
[harga yang disimpan dalam tabel harga: 10.00]
misalnya Untuk barang seberat 2kg, harganya menjadi 35$ (1,5g = 15$ + 0,5 = 20$)
3) Laptop: Mudah, $100. Tidak ada yang istimewa dalam hal ini, tidak ada batasan apa pun.
[harga yang tersimpan di tabel harga: 100,00]
misalnya Untuk barang seberat 2kg, harganya menjadi 35$ (1,5g = 15$ + 0,5 = 20$)
4) Karton: Ini dia yang menarik. Sampai saat ini hanya ada satu ketergantungan: weight
. Namun yang ini memiliki ketergantungan tambahan: dimension
. Ini agak mirip dengan kategori Dokumen. Untuk karton dengan ukuran di bawah 3 Kaki Kubik (CF), harganya adalah $80 per CF. Perbedaan antara kategori Dokumen dan Karton adalah, Dokumen memiliki harga tetap sedangkan Karton memiliki Harga Satuan. Tapi tunggu, masih ada lagi. Ada batasan tambahan: rasio dimensi-berat. Dalam hal ini adalah 7kg per CF
. Dan jika berat barang melebihi rasio, untuk setiap kg tambahan akan dikenakan biaya $5. Ini sangat membingungkan, saya tahu. Sebuah contoh mungkin bisa membantu:
[harga yang tersimpan di tabel harga: 80,00]
misalnya Untuk karton 80kg dan 2CF; harganya akan menjadi $490. Begini caranya:
Pertama hitung tagihan regulernya: 80$*2CF = 160$ Sekarang mari kita cari tahu apakah melewati Rasio: Karena, 1 CF = 7kg, maka 2CF = 14kg. Tapi berat barangnya 80kg, jadi melewati rasio (14kg)
Karena melintasi rasio, untuk semua kg tambahan (80-14 = 66kg), setiap kg akan berharga $5: 66*5 = $330. Setelah ditambahkan dengan tagihan reguler: 330$+160$ = 490$.
5) Karton Berat: Yang ini untuk karton yang dimensinya lebih besar dari 3CF. Bedanya dengan Karton adalah harga satuannya. Karton Berat adalah $60 per CF.
[harga yang tersimpan di tabel harga: 60,00]
misalnya Untuk karton 80kg dan 5CF; harganya akan menjadi $525. Begini caranya:
Pertama hitung tarif regulernya: 60$*5CF = 300$ Sekarang mari kita cari tahu apakah melewati Rasio: Karena, 1 CF = 7kg, maka 5CF = 35kg. Tapi berat barangnya 80kg, jadi melewati rasio (35kg)
Karena melintasi rasio, untuk semua kg tambahan (80-35 = 45kg), setiap kg akan berharga $5: 45*5 = $225. Setelah ditambahkan dengan tagihan reguler: 300$+225$ = 325$.
Jika Anda sudah membaca sejauh ini, saya rasa saya telah meyakinkan Anda bahwa struktur bisnis itu sangat rumit. Sekarang mari kita lihat skema categories
saya:
+-------------------------+---------------------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------------+---------------------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| name | varchar(191) | NO | | NULL | |
| created_at | timestamp | YES | | NULL | |
| updated_at | timestamp | YES | | NULL | |
| dim_dependency | tinyint(1) | NO | | NULL | |
| weight_dependency | tinyint(1) | NO | | NULL | |
| distance_dependency | tinyint(1) | NO | | NULL | |
| dim_weight_ratio | varchar(191) | YES | | NULL | |
| constraint_value | decimal(8,2) | YES | | NULL | |
| constraint_on | enum('weight','dim') | YES | | NULL | |
| size | enum('short','regular','large') | YES | | regular | |
| over_ratio_price_per_kg | decimal(8,2) | YES | | NULL | |
| deleted_at | timestamp | YES | | NULL | |
+-------------------------+---------------------------------+------+-----+---------+----------------+
Juga skema tabel prices
(ini adalah tabel polimorfik, berharap dapat membuat tabel subcategories
suatu hari nanti):
+----------------+---------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+----------------+---------------------+------+-----+---------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| amount | decimal(8,2) | NO | | NULL | |
| created_at | timestamp | YES | | NULL | |
| updated_at | timestamp | YES | | NULL | |
| priceable_type | varchar(191) | NO | MUL | NULL | |
| priceable_id | bigint(20) unsigned | NO | | NULL | |
| deleted_at | timestamp | YES | | NULL | |
+----------------+---------------------+------+-----+---------+----------------+
Bagaimana cara memperbaiki struktur ini agar segala sesuatunya tetap dinamis dan koheren?
User (USR) got price (PRI) for product (PRD) based on rule number (RNO).
Anda dapat mendokumentasikan aturan dalam sistem yang berbeda. - person Damir Sudarevic   schedule 11.08.2018