$var minus data fra database

man kunne have en database med
bruger: id, navn, andre stamdata
formue: id, bruger_id, dato/tid, beløb
når en bruger oprettes tildeles de fx et beløb på +500
og ved køb, så laves en sum på bruger_id og dennes beløb - er der penge nok, så tilføjes en post i formue med bruger_id, dato/tid og beløb (med minus)
formue-tabellen kan også linke til en tabel med opgraderingsmuligheder, så bruger kan se, hvad de har købt og historik sorteret på tid.

har gjort at de får tildelt 25000 når de oprettes de køber eks sæder til deres stadion så har lavet et if else altså hvis de har penge nok kommer der en knap der hedder køb og når de trykker på den skal den trække prisen fra saldo tabellen og tilføje sæder til stadionen tabellen

det er så det, jeg vil undgå - en saldo. Jeg vil hellere have, at du har fx
bruger (id, navn, adgangskode osv)
station (id, navn, maks antal pladser)
formue (id, bruger_id, beløb, dato/tid, vare_id) - vare_id kan referere til antal i pladser-tabel eller grund-beløb)
pladser (id, stadion_id, antal, bruger_id)
så skal et køb (hvis den beregnede saldo er ok, og der er ledige sæder) generere 2 poster:
en pladser med bruger_id, stadion_id og antal sæder
en formue med bruger_id, negativt beløb

nu spørger jeg måske lidt dumt men er det ikke lidt komplicerede at have 3 databaser der skal kommuniker med hinanden?

det er et spørgsmål om at styre data - jeg har foreslået en database med pt 4 tabeller og et antal poster.
Jeg har set mange systemer, hvor saldo ikke passede med antal køb/salg, så derfor vil jeg beregne saldo.
Det er jo ikke dig, der skal lave arbejde - det er et kald til databasen - din opgave er at lave et stabilt og sikkert system.

så det vil sige hver gang jeg opretter en bruger skal lave en ny station formue og pladser eller hvad

En bruger oprettes, og får en start-formue (en post i hver af de to tabeller).

Intet kan købes før der også er varer (fx station) og Stadion har så et antal pladser der kan købes (det kunne også være et højhus med lejligheder, der kan købes - eller varer uden begrænsning, fx vand, møbler osv )
Så der er køber/bruger med formue, og varer med antal og priser - du kan starte med at lave fx 20 varer, og lade brugere vælge, hvad de vil have, og hvor meget.
Du kan når som helst introducere nye varer (bil, cykel osv) og brugerne kan frit købe dem så længe de har penge og varen er tilstede på lager.
Systemet kan også regne med negative antal, så brugere kan sælges pladser på stadion, og bruge penge på lejlighed osv - evt kan folk, der vil have en plads på stadion give et bud, og en anden bruger kan sælge det direkte (måske med fortjeneste) Så bliver det kompliceret og spændende...

alle bruger får tildelt en stadion med 500 siddepladser når de starter og der vil altid være flere sæder til stadion altså der kan aldrig blive udsolgt og den kan blive så stor den vil  så længe man har play money til det og man kan ikke skulle sælge stadion da den tilhører bruger

okay - dine regler - du læser bruger-data, trækker de brugte penge fra, og genskriver posten. Så har du vel et sted, hvor du lægger antal pladser til, så de kan se, at de nu har mere end 500 - det er på samme måde - læs posten med brugers pladser, læg antal købte til og genskriv posten.

Jeg ville nok gaa efter en model med saldo.

At beregne saldo udfra transaktioner vil vaer enoget som vil tage laengere og laengere tid efterhaanden som antal brugere og antal transaktioner vokser.

Konsistens problemet skal loeses med brug af transaktioenr og et passende transaktions isolerings niveau.