Saya dapat memikirkan tiga solusi - EAV, XML, dan Sparse Columns. Yang terakhir ini khusus untuk vendor dan mungkin tidak berguna bagi Anda.
Metode apa pun yang Anda pilih, Anda mungkin ingin mempertimbangkan untuk menyimpan data permintaan asli dalam format mentah, dalam tabel atau file datar. Ini akan membuatnya mudah untuk mencoba cara-cara baru menyimpan data, memungkinkan Anda untuk memuat ulang data jika Anda menemukan kesalahan dengan cara Anda mem-parsing permintaan Anda, dan menawarkan peluang untuk mem-parsing permintaan API menggunakan pemrosesan batch atau "data besar" alat jika Anda menemukan bahwa gudang data Anda tidak dapat menangani data secara efisien.
Pertimbangan EAV
EAV / KVS, seperti yang telah Anda jelaskan di atas, kemungkinan merupakan implementasi yang paling mudah.
Sayangnya itu juga akan menjadi sangat mahal - untuk mendapatkan segala jenis pertanyaan efisien pada kunci yang biasa digunakan, Anda perlu memiliki indeks pada kolom kunci, yang bisa menjadi sangat terfragmentasi. Permintaan kunci tertentu akan sangat mahal.
Anda mungkin dapat mengurangi biaya pengindeksan atau pemindaian indeks dengan mendukung toko EAV Anda dengan tampilan terwujud (banyak vendor mendukung ini) untuk menanyakan kunci atau nilai yang Anda pedulikan.
XML
Sebagian besar sistem basis data perusahaan menawarkan penanganan XML yang sangat matang, termasuk validasi, pengindeksan, dan kueri canggih.
Memuat permintaan API ke dalam database karena XML akan menyediakan satu tuple per permintaan, yang secara logis mungkin sedikit lebih cocok untuk Anda daripada memiliki jumlah baris yang tidak diketahui dalam tabel EAV.
Apakah ini efisien akan sangat tergantung pada vendor RDBMS Anda dan implementasi Anda.
Kelemahan terbesar adalah bahwa ini mungkin satu-satunya cara mengelola data yang lebih rumit daripada manipulasi string dari permintaan asli!
Kolom Jarang / tabel tradisional
Mungkin Anda bisa memuat data Anda ke dalam struktur tabel tradisional, dengan satu kolom per kunci.
Fitur SQL Server's Sparse Columns adalah alternatif yang bagus untuk toko EAV. Tabel dengan Kolom Jarang berperilaku sama seperti tabel normal, kecuali bahwa tabel tersebut dapat memiliki hingga 30.000 kolom, dan nilai NULL dalam kolom jarang tidak menggunakan ruang dalam tabel.
Menggabungkannya dengan Indeks yang Difilter (fitur spesifik SQL Server lain) dapat memberikan alternatif yang sangat efisien untuk toko EAV jika Anda sering meminta beberapa kolom dan / atau nilai tertentu.
Menggunakan tabel tradisional dengan vendor lain mungkin layak - IBM mendukung lebih dari 700 kolom per tabel dan Oracle sekitar 1000, dan fitur seperti kompresi atau perlakuan Oracle terhadap trailing nulls dapat berarti bahwa Anda dapat menyimpan data API Anda dengan cukup efisien.
Kelemahan yang jelas dari pendekatan ini adalah bahwa ketika Anda menambahkan kunci baru ke API Anda, Anda harus menyesuaikan skema Anda.