Pada akhirnya, ia menggunakan dan arsitektur.
Arsitektur
Apakah sistem menangani "olahraga apa pun"? Apakah gagasan bahwa Anda mengenakan topi astronot arsitektur Anda, dan membangun sistem generik yang dapat menangani semua jenis olahraga masa depan yang bahkan mungkin tidak ada saat ini?
Jika demikian, jelas memiliki tabel yang dinamai dinamis adalah rasa sakit yang sangat besar, jadi masuk akal untuk memiliki skema yang mendukung olahraga, jika diperlukan.
Yang mengatakan, saya memiliki bias yang sangat kuat terhadap pendekatan ini: ini hampir selalu lebih banyak bekerja dan mengarah pada hasil yang lebih buruk. Membuat UI, skema, dll yang terpisah, untuk setiap olahraga pada akhirnya akan mengarah pada pengalaman pengguna yang lebih baik dan lebih mudah untuk mempertahankan kode, bahkan jika itu berarti sejumlah duplikasi dangkal (bagaimana menghindari / meminimalkan ini adalah pertanyaan terpisah).
Bagaimana Anda menangani pemain yang memainkan banyak olahraga? Apakah mereka mendapat dua entri (mis. Anda memperlakukan sebagai orang yang berbeda) atau Anda mencoba melakukan sesuatu yang spesifik dengannya?
Menggunakan
Jadi anggaplah Anda tidak melakukan olahraga secara dinamis (misalnya, jika seseorang ingin menambahkan olahraga baru, itu memerlukan upaya pengembangan untuk menambahkannya).
Apakah pernah ada waktu di mana Anda menampilkan pemain (atau objek lain yang Anda sebutkan) dari lebih dari satu olahraga pada suatu waktu?
Saya bisa melihat ini untuk fungsi pencarian, di mana Anda bisa mencari berdasarkan nama pemain atau tim (terlepas dari olahraga), tetapi di luar itu saya tidak bisa membayangkan banyak kasus penggunaan.
Jika Anda tidak perlu melakukan ini, maka pendekatan Anda baik-baik saja. Anda bisa berhenti membaca di sini.
Skema Alternatif
Tampilan
Saya penggemar CIUMAN. Dalam 15+ tahun pengembangan perangkat lunak, saya terus kembali ke filosofi "membangun hal paling sederhana yang berhasil".
Jadi reaksi awal saya, dengan asumsi fungsi pencarian lintas-olahraga adalah satu-satunya kasus penggunaan, adalah membuat tampilan:
SELECT PlayerName, 'NFL' as [Sport], TeamName FROM NFL_Players JOIN NFL_Teams ...
UNION
SELECT PlayerName, 'NHL' as [Sport], TeamName FROM NHL_Players JOIN NHL_Teams ...
UNION ....
Tentu saja, jika Anda menambahkan olahraga baru, Anda harus menambah tampilan. Mungkin juga berguna untuk memasukkan informasi umum lainnya tetapi sebenarnya itu tergantung pada apa yang perlu ditampilkan.
Saya akan mencoba untuk menyimpan semua hal khusus olahraga dalam definisi Lihat, jadi kode pencarian tidak perlu memiliki banyak atau kode spesifik apa pun (selain mungkin mengetahui cara menautkan ke /nhl/players/player-name
vs /nfl/...
atau bagaimanapun aplikasi Anda melakukannya).
Warisan Tabel
Warisan tabel bisa berfungsi, tetapi cukup rumit. Saya tidak punya banyak pengalaman dengannya, dan pada kenyataannya, saya pikir setiap kali saya terlibat dalam mengevaluasinya, kami akhirnya melakukan sesuatu yang lebih sederhana (seperti yang saya sarankan di sini).
Jadi secara pribadi, saya belum menemukan mengapa ini akan berguna, tetapi mungkin ada kasus penggunaan yang meyakinkan (yang saya tidak tahu) yang membenarkan kerumitan (misalnya, warisan Tabel memecahkan kasus penggunaan lebih baik daripada solusi lain) .
Tabel terpisah untuk atribut khusus olahraga
Anda bisa melakukan satu players
tabel yang memiliki atribut umum untuk semua pemain dari semua olahraga, dan kemudian satu set tabel seperti nhl_players_details
itu yang berisi ID player dan kolom dengan info tambahan tentang pemain. Jika ada banyak atribut umum, atau Anda memiliki banyak kegunaan "semua pemain dari semua olahraga" maka ini mungkin masuk akal.
Pasangan nilai kunci untuk atribut khusus olahraga
Pendekatan yang sama sekali alternatif: memiliki players
meja (sekali lagi, dengan atribut umum seperti nama) dan kemudian player_data
meja yang memiliki PlayerId
, Sport
, Attribute
, Value
. Nama atribut yang dimasukkan akan spesifik untuk olahraga. Ini memungkinkan Anda untuk secara esensial menambahkan atribut baru tanpa memodifikasi skema (kode Anda masih harus tahu untuk memuat / menampilkannya tentu saja). Kekurangannya adalah Anda kehilangan integritas: nilai biasanya berupa bidang string, jadi kode aplikasi Anda harus tangguh dan menangani potensi kegagalan mengonversi string value
ke tipe data tertentu (seperti integer).
Konsep ini tentu saja dapat berlaku untuk Tim, Permainan, dll.