login  Naam:   Wachtwoord: 
Registreer je!
 Forum

update of replace zonder premaire key

Offline markla - 28/11/2013 09:28
Avatar van marklaPHP interesse wekelijks doe ik een handmatig update van de voetbalstand door na het invoeren van de uitslagen een query te draaien en het resultaat daarvan in een andere tabel te stoppen.

Ik zou dat echter handiger vinden om via een script te laten lopen.
Er is echter één probleem. De output die ik wil importeren bevat niet de waardes van de premaire key: af_endranking_id. Nu zijn de velden af_season_id+af_position ook een unieke key. Is er een mogelijkheid met een script deze waardes

php code - Bekijk de code zonder highlighting - Klap code in 
  1. af_endranking_id 	af_season_id 	af_position 	af_team_id 	af_numgames 	af_win	af_draw	af_lost	af_point	af_goalsmade 	af_goalsagains
  2. 1534	109	1	42	13	7	3	3	24	25	18
  3. 1535	109	2	5	13	7	2	4	23	23	19
  4. 1536	109	3	4	13	6	4	3	22	25	15
  5. 1537	109	4	16	13	6	4	3	22	28	25
  6. 1538	109	5	17	13	5	6	2	21	28	12
  7. 1539	109	6	20	13	6	3	4	21	27	21
  8. 1540	109	7	66	13	5	5	3	20	22	14
  9. 1541	109	8	31	13	5	4	4	19	24	14
  10. 1542	109	9	35	13	5	3	4	18	29	25
  11. 1543	109	10	27	13	5	3	5	17	22	18
  12. 1544	109	11	34	13	4	5	4	17	22	28
  13. 1545	109	12	21	13	4	4	4	16	20	29
  14. 1546	109	13	18	13	4	3	6	15	17	25
  15. 1547	109	14	46	13	4	2	6	14	16	22
  16. 1548	109	15	3	13	4	1	7	13	17	27
  17. 1549	109	16	8	13	3	3	7	12	11	17
  18. 1550	109	17	33	13	2	3	8	9	18	29
  19. 1551	109	18	28	13	1	6	6	9	19	35


vervangen/updaten met deze waardes

[code]
af_endranking_id af_season_id af_position af_team_id af_numgames af_win af_draw af_lost af_point af_goalsmade af_goalsagains
109 1 42 14 8 3 3 27 28 18
109 2 4 14 7 4 3 25 28 15
109 3 17 14 6 6 2 24 33 14
109 4 5 14 7 3 4 24 25 21
109 5 16 14 6 5 3 23 28 25
109 6 66 14 5 6 3 21 22 14
109 7 20 14 6 3 5 21 27 22
109 8 31 14 5 5 4 20 25 15
109 9 35 14 5 4 4 19 30 26
109 10 18 14 5 3 6 18 20 25
109 11 34 14 4 6 4 18 24 30
109 12 26 14 5 3 6 17 24 23
109 13 21 14 4 4 5 16 20 32
109 14 8 14 4 3 7 15 13 18
109 15 46 14 4 2 7 14 16 25
109 16 3 14 4 1 8 13 17 30
109 17 33 14 3 3 8 12 19 29
109 18 28 14 1 6 7 9 20 37
[code]

3 antwoorden

Gesponsorde links
Offline Thomas - 28/11/2013 11:48
Avatar van Thomas Moderator De combinatie af_season_id + af_position is wellicht uniek, in die zin dat een team in elk seizoen precies één positie bekleed, maar deze positie kan door een win- of verliesbeurt kunnen gaan toebehoren aan een ander team (team promoveert/degradeert n.a.v. een uitslag). Daarom lijkt mij deze combinatie niet echt geschikt als "identificerend attribuut(paar)".

Wat ik voor de UPDATE-statements zou gebruiken is af_season_id en af_team_id maar als je op grond hiervan een UPDATE query uitvoert komt je in de knoei met de unique constraint op af_season_id + af_position, of je moet alle UPDATE-queries uitvoeren in een volgorde waarmee je de (tijdelijke) introductie van een dubbel af_season_id + af_position vermijd, of je moet tijdelijk je KEYS disablen tijdens het uitvoeren van je UPDATE-proces maar dat lijkt mij niet de bedoeling.

Ik denk dat de beste oplossing een herstructurering van je database is, het lijkt namelijk alsof je meerdere zaken (wedstrijden, uitslagen, stand in het klassement) in één tabel hebt proberen te verenigen.

De stand in het klassement is de uitkomst van een of andere berekening, het kan handig zijn om de uitkomsten van berekeningen op te slaan in een database(tabel) maar deze gegevens zijn in zekere zin redundant (afleidbaar uit andere zaken (wedstrijden + scores)). Maar nu staat dus alles bij (of door) elkaar . Als de berekening van de stand in het klassement te vangen is in PHP (of zelfs in MySQL), dan zijn straks de uitkomsten van de wedstrijden (en door welke partijen deze gespeeld zijn, en in welk seizoen) het enige wat je als gebruiker hoeft in te voeren, de rest is afleidbaar!

Als ik bovenstaande gegevens bekijk, heb je ongeveer de volgende tabellen/informatie nodig:

seizoenen
id
datum_begin
datum_eind

teams
id
naam
...

wedstrijden
id
datum
seizoen_id
partij_thuis_team_id
partij_uit_team_id
score_thuis
score_uit
(en mogelijk hier een soort van (redundante) indicatie van wie de wedstrijd heeft gewonnen, bijvoorbeeld: winnaar_partij_id met het partij_id van de winnaar of geen partij_id (NULL) in geval gelijkspel)

En dan, als het handig is om deze resultaten te "cachen" een tabel
ladders (ofzo)
seizoen_id
positie
partij_id
totaal_X (wat je allemaal wilt bijhouden in totaalscores)
totaal_Y
totaal_Z
...
Elke keer als je de ladder bijwerkt verwijder je alle entries van het huidige seizoen, en bereken je deze opnieuw.

Come to think of it, dat kun je dus ook doen met jouw data hierboven. Als af_endranking_id verder helemaal geen betekenis heeft (het dient alleen als auto_increment veld) kun je alles van seizoen 109 wegkieperen en alles opnieuw INSERTen.

Toch zou ik serieus overwegen om je database wat gestructureerder op te zetten, en alle afgeleide/berekende gegevens te verplaatsen naar een aparte resultaattabel, of, als deze berekening redelijk triviaal is, deze elke keer on-the-fly uit te voeren.
Offline markla - 28/11/2013 12:59
Avatar van markla PHP interesse @FangorN thanks voor je uitgebreid meedenkt.

De database bestaat iid uit meerdere tabellen zoals seizoenen, team, games, eindstand, etc. Daarbij heb ik dus één tabel Endranking. Aangezien de eindstand van een seizoen nooit meer zal veranderen is dat een "statische" table.
Daarin wil ik voor het lopende seizoen de huidige (tussen)stand als eindstand hebben.

Misschien in de verre toekomst wil ik ook de "tussenstanden" per speelronde van eerdere seizoen hebben, maar dat is heel veel data, lees uitzoekwerk, waar ik nu nog niks mee doe.

Voor die tussenstanden geldt weer dat iedere ronde de positie aan een ander team kan toebehoren. Vandaar mijn vraag over de samengestelde key af_season_id+af_position

MAAR!!  Jou redenatie over de ladders lezend overwegen nu van iedere speelronde de tussenstand toe te voegen en dan de recentste als actuele stand te tonen. Dan heb ik nu wat ik wil en later ook de tussenstand per speelronde.

Nogmaals thanks!
Offline Thomas - 28/11/2013 13:09
Avatar van Thomas Moderator Ah, dat voert nog wat verder dan ik dacht: een extra tijd-element (rondes) in de "huidige eindstand" tabel . Ik dacht dat je alleen de meest recente tussenstand wilde hebben, maar als je hier een historie van bijhoudt hoef je nooit meer iets opnieuw te berekenen, heeft ook zo zijn voordelen.

Daarnaast, mocht er iets mis zitten in de berekening, heb je de originele data ook nog dus kun je de resultaat-tabel te allen tijde repareren (opnieuw berekenen). Ook daarom is het handig om je "bron" data en "berekende" data gescheiden te houden.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Actieve forumberichten
© 2002-2024 Sitemasters.be - Regels - Laadtijd: 0.189s