Pertanyaan Opsi desain tabel untuk banyak baris?


Saya memiliki aplikasi yang mengirim data berdasarkan interaksi pengguna (bukan input pengguna). Data yang dikirim bisa berupa nilai Integer, String, Date, atau Boolean. Ada 140 kunci. Kita bisa mendapatkan di mana saja dari 1 pasangan nilai kunci ke semua 140 pada suatu waktu.

Kami ingin menyimpan semuanya tetapi hanya akan menggunakan 20 dari 140 kunci dalam aplikasi. Sisanya akan digunakan untuk jejak audit nanti - jadi kita masih perlu menyimpannya.

Data ini digunakan oleh aplikasi untuk memutuskan ke mana pengguna harus pergi sehingga perlu mengakses catatan oleh id siswa dan menarik 20 atau lebih opsi dalam milidetik. Mungkin ada miliaran baris data (ini merupakan peningkatan ke aplikasi yang sudah ada dengan lebih dari 20.000 pengguna) sehingga kinerja sangat penting. Pengguna menghasilkan baris baru setiap kali mereka mengakses aplikasi.

CONTOH DATA:

Score:1
ID:3212
IsLast:False
Action:Completed

Saya memiliki 2 ide tentang bagaimana melakukan ini dan mencari bantuan yang terbaik atau pilihan ketiga adalah pilihan yang lebih baik.

PILIHAN 1:

Ide pertama saya adalah menggunakan kolom untuk nilai sebagai string kemudian memiliki tabel mencari tipe data yang mungkin untuk digunakan ketika nilai perlu Cast untuk digunakan.

value       | dataType
-----------------------
"1"         | int
"Completed" | string

Sementara data yang dikirim tidak dihasilkan oleh pengguna, saya tahu pasti ada cara untuk mendapatkannya di suatu tempat dalam metode ini. Satu-satunya alasan untuk melakukan ini adalah bahwa kita tidak tahu kunci apa: pasangan akan dikirim (di luar tanggal dan id) dan mencoba menghindari lebih dari beberapa kolom.

Pertanyaan SO Cara Menangani Jenis Data Tidak Dikenal dalam satu Tabel menggunakan ide yang serupa.

PILIHAN 2:

Solusi lainnya adalah memiliki 140 kolom - satu untuk setiap kunci. Namun, jumlah data yang dihasilkan sangat besar (miliaran baris) sehingga memanggil data ini tidak akan cukup cepat - saya tidak berpikir.

Detail Teknis: Ini menggunakan SQL Server 2008 - bukan R2 dengan DotNet C # dan Layanan Pelaporan.

Apakah saya kehilangan sesuatu di sini - apa cara terbaik untuk membuat tabel ini untuk kinerja?


5
2018-02-24 15:38


asal


Jawaban:


Segarkan data Anda secara vertikal. Masukkan 20 kunci yang diperlukan untuk kontrol navigasi dalam satu tabel, semua 20 dalam satu baris, dengan PK yang mengidentifikasi Interaksi pengguna (Callit mengatakan, InteractionId). Masukkan 120 nilai lainnya di tabel lain, dengan kunci primer gabungan, berdasarkan PK dari tabel pertama (InteractionId, ditambah KeyTypeId mengidentifikasi yang mana dari 120 pasangan kunci yang mungkin untuk nilai itu. Simpan semua nilai dalam tabel kedua ini sebagai string. Di tabel pencarian ketiga yang disebut, katakan, KeyTypes, simpan KeyTypeId, KeyTypeName, dan KeyValueDataType untuk memungkinkan kode Anda mengetahui cara mentransmisikan nilai string untuk menampilkannya dengan baik sebagai string, datetime, integer, atau nilai desimal atau apa pun ...

Tabel pertama akan diakses lebih sering, sehingga hanya berisi nilai-nilai yang mana fungsi navigasi aplikasi memerlukan akses lebih sering, menjaga baris lebih sempit, yang memungkinkan lebih banyak baris per halaman, dan meminimalkan disk IO. Menempatkan semua 20 nilai dalam satu baris akan menjaga jumlah baris lebih kecil (~ 1 / 20th besar), meminimalkan kedalaman indeks pencarian yang perlu dilakukan untuk setiap akses.

Tabel lainnya dengan semua 120 nilai kunci lainnya tidak akan sering diakses, sehingga strukturnya mungkin dapat dioptimalkan untuk kesederhanaan logis daripada untuk kinerja.


6
2018-02-24 15:48



Sebenarnya, Anda mungkin menggabungkan saran yang ditawarkan sejauh ini:

Buat tabel dengan 20 tombol yang diperlukan untuk kontrol navigasi, ditambah satu kolom untuk Kunci Primer, ditambah satu kolom yang merupakan tipe data XML untuk menyimpan sisa data yang mungkin. Anda kemudian dapat membuat DTD yang menangani tipe data untuk setiap kunci, ditambah kendala pada kunci tertentu sesuai kebutuhan.


2
2018-02-24 15:55



Yah itu harus cukup sederhana untuk menguji kedua ide, tetapi variasi pada opsi 1 terlihat disukai oleh saya. RDBMSs seperti SQL Server lebih memilih tabel yang panjang dan sempit (yaitu lebih sedikit kolom tetapi banyak baris).

Saya tidak akan melangkah lebih jauh karena tampaknya Charles telah mengalahkannya, dengan saran yang sangat masuk akal.


1
2018-02-24 15:51