Saya relatif baru lulus dari perguruan tinggi sehingga sebagian besar keakraban saya dengan database relasional adalah dari kursus database saya di mana apa pun yang tidak di BCNF atau 3NF adalah sebuah parodi. Tentu saja itu salah satu ujung yang ekstrem, tetapi tim saya di tempat kerja tampaknya benar-benar membawanya ke ujung yang berlawanan.
Dalam skema microservice db kami, entitas jarang memiliki lebih dari satu tabel. Apa pun yang biasanya Anda normalkan ke tabel lain disimpan dalam kolom json. Jika nanti ditemukan bahwa salah satu properti dalam json ini perlu ditanyakan, kolom baru ditambahkan dan data disimpan di kedua tempat (ya, dalam dua kolom berbeda di tabel yang sama).
Dalam banyak kasus, kolom json ini pasti memiliki keunggulan. Jika Anda tidak pernah perlu menanyakan data itu dan jika Anda tidak perlu membuat perubahan unilateral untuk data itu (yang merupakan sesuatu yang jelas tidak dapat Anda prediksi), itu bukan ide yang buruk. Ditambah banyak layanan kami yang tidak melihat server atau dihosting di mesin dengan jumlah ruang disk yang tidak sesuai untuk apa yang mereka butuhkan, sehingga duplikasi data bukan masalah besar. (Meskipun sesuatu yang saya umumnya ingin hindari dari filsafat)
Saat ini kami sedang membangun layanan yang cocok dengan aturan berdasarkan seperangkat kondisi yang mereka miliki dan kemudian melakukan serangkaian tindakan yang terkait dengan aturan tersebut ketika aturan itu benar (misalnya semua persyaratan itu benar). Sub tim saya yang paling cepat membangun layanan ini percaya bahwa ada manfaat besar untuk menormalkan tindakan dan ketentuan yang jauh dari aturan dalam skema. Jelas tabel ini memelihara hubungan kunci asing dengan id aturan. Dari sudut pandang kami, kami dapat menghindari duplikasi data pada kondisi yang memungkinkan kami memastikan bahwa mereka hanya dievaluasi satu kali dan mudah untuk menemukan kondisi dan aturan yang kami butuhkan saat membutuhkannya tanpa harus menarik setiap aturan dan melakukan pencarian dalam memori.
Berbicara dengan salah satu insinyur utama kami hari ini, ia berusaha mendorong saya jauh dari skema ini. Mencoba berdebat dalam segala hal yang kita lakukan sebenarnya tidak membutuhkannya, itu akan menyebabkan masalah kinerja di masa depan, merujuk pada monolit lama yang kita miliki yang merupakan desain yang tidak benar. Dia menyebut apa yang kita lakukan sebagai "jalan lama" dan meja datar dengan json sebagai "jalan baru". Dia berpendapat bahwa di tempat-tempat di mana saya menginginkan atomisitas, kita tidak memerlukannya dan bahwa alih-alih bertanya kita harus melakukan lebih banyak hal dalam memori. Ini adalah prinsip desain yang diikuti oleh banyak layanan kami sekarang. Kami tidak mengantisipasi bahwa volume data kami akan tumbuh secara substansial yang seharusnya menjaga kueri kami dengan cepat. Apa yang kami antisipasi adalah banyak waktu yang dihabiskan dalam evaluasi aturan dan melakukan tindakan.
Saya mengerti bahwa basis data non-relasional telah menjadi lebih populer dalam beberapa tahun terakhir, tetapi bahkan ketika secara aktif mencari informasi tentang implikasi kinerja hubungan kunci asing, saya tidak melihat banyak informasi membuat masalahnya. Saya kira mereka mungkin cenderung untuk memperkenalkan transaksi besar yang dapat menyebabkan masalah, tetapi itu tampaknya seperti masalah yang terlepas dari kunci asing itu sendiri.
Apakah ini kenaifan saya? Atau apakah ini benar-benar ada sesuatu yang saya dan sub-tim saya hilang? Saya secara eksplisit tidak memberikan informasi terperinci tentang masalah kami karena saya belum tentu mencari solusi untuk itu. Mengingat itu adalah tren umum di tim kami yang lebih besar, saya benar-benar ingin tahu apakah mereka melakukan sesuatu dengan ini.