Saya bertanya-tanya tentang kinerja dan kelemahan arsitektur dari menimpa tabel sepenuhnya dengan setiap pembaruan (jarang).

Karena beberapa persyaratan aneh, database MySQL saat ini bertindak sebagai penyimpanan untuk GraphQL API. Itu tidak memiliki batasan kunci asing dan tidak ada fitur mewah lainnya, dan memiliki kunci INT primer yang tidak berarti. Saat ini saya sedang mengerjakan skrip yang mengisinya dengan data pembaruan yang lambat, secara efektif satu file teks yang dapat dibaca manusia per baris.

Kekhawatiran saya adalah bahwa dengan file teks baru, kunci utama yang dihasilkan secara alami akan berubah, dan orang mungkin ingin menanyakannya melalui API. Saya tidak ingin melacak ID dalam file teks dan ON DUPLICATE KEY UPDATE tabel.

Cukup memindai setiap file teks dan memotong tabel untuk kemudian diisi ulang tampaknya mudah dan efisien, tetapi apakah ada cara yang lebih baik atau sesuatu yang mungkin saya temui dengan metode ini? Terima kasih.

1
StockHuman 24 Mei 2020, 19:14

1 menjawab

Jawaban Terbaik

Ini praktik yang baik untuk mengabstraksi kunci utama dari konsumen API Anda - ini menjamin kolom lain di tabel Anda seperti file_index. Memisahkan data dari indeks juga akan membantu memisahkan masalah pemeliharaan basis data dari masalah/pengembangan API.

Untuk kemungkinan jebakan, sebaiknya hindari menghapus dan/atau memperbarui data bila memungkinkan. Bukannya itu ide yang buruk, tetapi memperkenalkan kompleksitas yang harus dibenarkan oleh fungsionalitas yang disediakannya.

Secara umum, solusi yang lebih kompleks dapat diterapkan tetapi akan membutuhkan investasi waktu yang lebih besar dalam pengembangan dan (terutama) pengujian agar sekuat alternatif yang lebih sederhana.

Saya akan menambahkan kolom seperti file_index MEDIUMINT NOT NULL AUTO_INCREMENT tanpa indeks, dan memberikan nilai itu kepada konsumen API saya jika mereka membutuhkan bilangan bulat unik untuk setiap file.

1
David Miner 26 Mei 2020, 03:41