2v2 için Veritabanı Yapısı oyunu

Düzenli olarak 12 arkadaşımla 2v2 oyunu oynuyorum ve bir sıralama sistemi oluşturmak amacıyla oyuncuları, takımları, skorları ve oyunları takip etmek için bir veritabanı istiyorum.

Düzenli ekipleri değiştirmek beri tablolarla geldim players, teamsve gamesoyunlar iki takım (team1 ve Team2) sahip ve nerede ekipleri iki oyuncu (player1 ve player2) oluşur.

Bu oldukça az soruna neden olur - örneğin birlikte oynamak için iki oyuncu seçersem (onlara A ve B diyelim), Oyuncu1'in A ve Oyuncu2'nin B veya Oyuncu1'in B ve Oyuncu2 olduğu bir takım olup olmadığını kontrol etmeliyim A.

Sütunlar gamesve winshem playerstabloda hem de tabloda bulunur teams- ancak bunun nedeni, hem oyuncular tarafından kaç oyun kazanıldığını, hem de oyuncunun farklı takımlarda ne kadar uyumlu olduğunu görmek istiyorum (bir takımla ne zaman kazanır? başka bir belirli oyuncu).

1. Sıralama puan tahtası (Muhtemelen Elo derecelendirme sistemini kullanacağım )
2. Her oyuncu için derecelendirme, galibiyet, oyunlar, son oyun istatistikleri ve en çok hangi oyuncularla uyumlu olduğu için bir istatistik sayfası.

Bunun çoğunun veritabanı normalizasyonundaki bazı ilkeleri ihlal ettiğinden şüpheleniyorum ve veritabanı tasarımımı nasıl uygulayacağım konusunda bazı önerileri çok isterim.

Geçerli şemanızla gördüğüm iki sorun var, bir tanesi, bir bileşik anahtarın etkili bir şekilde kopya olup olmadığını belirlemek için bir tablodaki iki alanı kontrol etmek zorunda kalmak ve bazı toplu veriler ayrı ayrı tablolara ayrılmak için toplanıyor varlıklar (özellikle kazanır, aynı zamanda oyuncunun reytingini de kazanır).

İlk sayı için, bir bileşik anahtarın herhangi bir alanının / herhangi bir alanının aradığınız OR biçiminde işlenmesini sağlayacak DB içi hileler yoktur, ancak DB'niz destekliyorsa, getPlayerTeams(player_id)kapsüllemek için bir işlev oluşturabilirsiniz sorgu.

(Ayrıca, team_thumbprint ile sıralı oyuncu kimliklerinin karması olarak hesaplanan bir görünüm oluşturabilirsiniz, böylece aynı iki kişinin herhangi bir kombinasyonu her zaman aynı parmak iziyle sonuçlanır, ancak bu biraz fazla olabilir).

Normalleştirmeye gelince, team_resultbelirli bir takımın tüm sonuçlarını izlemek için bir tablo kullanarak varlıkları sonuçlardan ayırmayı düşünün . Biraz daha aşırı normalizasyon player_rating_hist, bir oyuncu için tüm derecelendirme değişikliklerini içeren bir tabloyu da gerektirir . Mevcut notları en güncel tarihe sahip olanlardır. Kolay sorgulama için en son değeri içermek üzere bir oynatıcı görünümü de kullanılabilir.

Önerilen şema (üzgünüm diyagram yok):

player
    id
    name
    created_on
    updated_on

player_rating_hist
    player_id (FK)
    rating
    rating_date

team
    id
    player1_id (FK)
    player2_id (FK)
    created_on
    updated_on

game
    id
    team1_id (FK)
    team2_id (FK)

team_game
    team_id (FK)
    game_id (FK)
    result
    score
    rating_change

team_rating_hist
    team_id (FK)
    rating
    rating_date

Sorguları:

--Results for the game, should only ever be two rows for any given game
SELECT * FROM team_game WHERE game_id = 101

--All results for a team
SELECT * FROM team_game WHERE team_id = 123456 

Bu yapı, "temel" varlıkları (oyuncular ve takımlar), sistemin zaman içinde çalışmasının bir sonucu olarak ortaya çıkan "içerikten" ayırmanıza olanak tanır ve temel tablolardan birini geçerli derecelendirmeyle sürekli olarak güncellemediğiniz anlamına gelir. Bunlar türetilmiş değerlerdir ve en son derecelendirmeyi, ortalama derecelendirmeyi, COUNTkazanç veya kayıpları vb. elde ederek alınmalıdır . Sistem yeterince büyüdüğünde, bu tür toplu verileri ayrı bir "depoya" çıkarmayı düşünebilirsiniz. (aynı DB'de yalnızca ayrı bir tablo grubu olsa bile) daha kolay analiz için.