Azami öznitelik sayısı bilinmeyen bir varlık nasıl uygulanır?

Bir beyzbol simülasyon programı tasarlıyorum ve boxscore şemasını tasarlarken bir sorunla karşılaştım. Sahip olduğum sorun, her bir atışta kaç koşu puanlandığını takip etmek istiyorum. Bunu gerçek programda yapmanın yolu, oynanan her vuruş için büyüyen dinamik bir dizi kullanmaktır.

Beyzbol oyununa aşina olmayanlar için, oyun 9. atışın sonunda hala bağlı değilse, oyunlar genellikle dokuz inning uzunluğundadır. Bu nedenle, beyzbol oyunları belirsiz bir uzunluğa sahiptir, bu da her bir atışta (9 teknik olarak 18 (9-inning * 2-takım) puanlanan koşular için sadece 9 sütun olacak şekilde veritabanını tasarlayamayacağım anlamına gelir. ve veritabanında saklamak önce Base64 olarak kodlamak.Ancak, bu kullanmak için iyi bir teknik olup olmadığını bilmiyorum ve kimse daha iyi bir fikir olup olmadığını merak ediyordum.

Önemli olması durumunda geliştirdiğim veritabanı PostgreSQL'dir.

Herhangi bir öneri büyük takdir! Teşekkürler!

Bunu yapabilirsin. Uzun süreli oyunları da saklamanıza izin verirken normal süreli oyunlar için iyi performans sağlar.

CREATE TABLE InningRuns (
    GameId INT NOT NULL REFERENCES [...],
    Team CHAR(4) NOT NULL, --'Home','Away'
    Inning1 TINYINT, --Seeing how more than 255 runs are not really possible in an inning
    Inning2 TINYINT,
    [...],
    Inning9 TINYINT,
    ExtraInnings XML | TINYINT[] | VARBINARY | ETC., --Use to hold any runs in extra innings.
    PRIMARY KEY (GameId, Team)
)

Daha fazla normalleştirebilir ve oyun, takım ve inning'in her benzersiz kombinasyonu için bir sıraya sahip olabilirsiniz. Bu, InningId veri tipinin izin verdiği kadar çok inning'e izin verir.

CREATE TABLE InningRuns (
    InningRunId INT IDENTITY PRIMARY KEY,
    GameId INT NOT NULL REFERENCES [...],
    Team CHAR(4) NOT NULL, --'Home','Away'
    InningId TINYINT, --Seeing how more than 255 innings might be excessive
    Runs TINYINT,
    UNIQUE (GameId, Team, InningId)
)

Düzenleme : PostgreSQL IDENTITY yerine Sequences kullandığını biliyorum, doğru sözdizimini elden hatırlamıyorum, bu yüzden buna göre tercüme edin.

Ben sadece bir sütun var yanlış bir şey olduğunu sanmıyorum

inning_score int[]

1'den 9'a kadar ve ötesinde. Bir dizi kullanmanın makul olabileceği birkaç yerden biri.

Burada gördüğüm şey biraz çelişkili, çünkü inning dolaylı hariç, gerçekten doğrudan oyunların bir özelliği değil. Ama belki bu sadece benim. Şahsen bir RunsScored tablosu gibi bir şey önermek ve geri bir çeşit GamesHeader tabloya bağlantı var, bu yüzden düşünün:

CREATE TABLE GamesHeader (
    GameID     INT IDENTITY(1,1),
    HomeTeamID INT,  --FK to teams table, naturally
    AwayTeamID INT,  --FK to teams table, naturally
    FinalInningsCount BYTE,  -- for faster reporting after the game is over
    FinalHomeScore BYTE,     -- for faster reporting after the game is over
    FinalAwayScore BYTE,     -- for faster reporting after the game is over
    --Other attribs
)

CREATE TABLE RunsScored (
    RunsScoredID BIGINT IDENTITY(1,1), -- for faster reverse traversal, possibly. May not be needed, this depends on your setup, as the normalization will show a composite key anyways
    PlayerID INT,   --FK to players table naturally
    GameID INT,     --FK to GamesHeader table naturally
    Inning BYTE, --wait for the payoff
    RunsEarned,     --because you may want to track this by the player ... really the problem is that there's not a single naturalized setup for this, so you may be intersecting this table to another stats table elsewhere. idk, it depends on your model. I'm going for fairly simplistic atm. Wanted to demonstrate something else entirely, but this needs to be accounted for.
     -- other attribs
)

SELECT MAX(r.Inning) FROM RunsScored r JOIN GamesHeader g ON g.GameID = r.GameID WHERE GameID = 'x'

Bu size belirli bir oyun için oynanan maksimum Inning'i verir ve isterseniz daha fazla ayrıntı bulmak için PlayerID -> TeamID ile daha da hassaslaştırabilirsiniz. Bunlar ne olabilir emin değilim.

Muhtemelen ikinci tabloyu RunsScored değil, AtBat hakkında bir şey olacak şekilde geliştiririm çünkü gerçekten izlediğiniz şey budur. Sadece oyun masasından tonlamayı nasıl denormalize edebileceğinizi göstermek istedim. Modelimi böyle akacak şekilde düzenlerdim, bu benim projem olsaydı. HTH. YMMV.

Ayrıca TSQL'li bir adam olduğumu unutmayın, ancak aşağıda ifade edilen kavramların konseptimi açıklamak için oldukça iyi çalıştığını düşünüyorum. Dil semantiği muhtemelen sıraya girmez.