Associative array vs database: rule of thumb?

[Paxcow]

Greetings.

Newbie question here:

Do you have a rule of thumb on what to store in a database vs an associative array?

I read the documentation and watched/reimplemented the tutorials and a couple of published games. I understand the general recommendation that static information (e.g. all the cards in a deck, with attributes, etc.) are better stored in materials php file.
The doc says to consider database to store dynamic state information (e.g. card location, etc).

I suppose that the same can be achieved though with an associative array.
A simple database that has CARD_ID | CARD_LOCATION | CARD_STATE could be easily modeled also with the following array:

Code: Select all

$cards_snapshot = array(
$card_id => array(
"location" => $card_location;
"state" => $card_state;
)
)

I suppose databases have better search capabilities with SELECT, while an array at some point would force you to cycle through its elements. Is that the reason?

In many cases I have seen, the code accesses the database only in very few occasions, and most of the operations are done with arrays at runtime.

So what are your reasons to use a database? What am I missing?

[RicardoRix]

Some data in an array will simply disappear at the end of the server call.
Web pages are generally stateless. I'm guessing you haven't done any web programming before.
You have to be able to persist the state of the data. Who's turn it is, what the score is, who has what resources...
A DB is the natural choice for doing that.
https://en.wikipedia.org/wiki/LAMP_(software_bundle)

If you like associate arrays a lot them BGA have a DB function specifically for that:
getCollectionFromDB( string $sql, bool $bSingleValue=false ) array
https://en.doc.boardgamearena.com/Main_ ... e.game.php

A long time ago I did some research into ASP.NET and different abilities with persisting data in different ways on the server.
Turns out DB's are lightning quick and very versatile.

[tchobello]

Greetings.

Newbie question here:

Do you have a rule of thumb on what to store in a database vs an associative array?

I read the documentation and watched/reimplemented the tutorials and a couple of published games. I understand the general recommendation that static information (e.g. all the cards in a deck, with attributes, etc.) are better stored in materials php file.
The doc says to consider database to store dynamic state information (e.g. card location, etc).

I suppose that the same can be achieved though with an associative array.
A simple database that has CARD_ID | CARD_LOCATION | CARD_STATE could be easily modeled also with the following array:

Code: Select all

$cards_snapshot = array(
$card_id => array(
"location" => $card_location;
"state" => $card_state;
)
)

I suppose databases have better search capabilities with SELECT, while an array at some point would force you to cycle through its elements. Is that the reason?

In many cases I have seen, the code accesses the database only in very few occasions, and most of the operations are done with arrays at runtime.

So what are your reasons to use a database? What am I missing?

you are allowed to use JSON data and store them in a fancy database if you prefer...

[Paxcow]

Thanks.

Actually as soon as you mentioned it clicked immediately. I did web development way back in the day, using PHP, mySQL and JS with AJAX, but not in this heavy client/server model, so the persistence was mostly done at client side...but that wouldn't cover the Refresh (F5) situation, so yes, db is the way.

edit: and of course the client should not contain any private info from other players.

Thanks, it makes a lot of sense

[BaronFraser]

Hail!

Just to clarify the above replies even further:

A separate instance of your game class is created on every call to the server. This means:

1. Whenever a game is created
2. Whenever a player loads the game into their browser (eg first visit, page refresh, returning to a Turn-based game)
3. Whenever an action api call is sent from the client
4. If you're using multiactive states, for each set of private args

NONE of these instances share data, so if you create an array when the game is created, that array won't be there when a player performs an action. The database is the way to persist data so that it's shared amongst all of these instances.

You could certainly write code so that when your instance is created, it repopulates an array in memory to manipulate throughout your code, but you must save that back to the database or else the changes will be forgotten.