All data in BigDB is stored in tables. Since BigDB is schemaless you do not specify any structure for the objects you store per table, but it's a good idea to keep different kind of objects in different tables, since you might want to put different indexes on them for lookups.
BigDB is administrated via the admin panel, where the developer has the abilities to:
Each BigDB table can have different access rights for each Player.IO connection type, so you can finely configure which data can be read and/or written from where.
It’s most important to think about the access rights for client side code like .swf files, in order to prevent cheating or even worse, users causing havoc by writing invalid data or even deleting everything.
For instance, you can configure it such that your clientside code only has access to read and write from a single, non-crucial table, while your other code like serverside multiplayer code or code running on your own servers has full access to all tables.
For some games, you might want to completely disallow all BigDB access from the client side, and run everything through server side code, while other games might be okay with trading security for speedy development.
It’s the tradeoff between security and convenience that has to be considered for every game. In order to give you the full control over this tradeoff for your game, you can setup different access rights for each table under each connection.
The access rights that can be set for each table are:
Can load database objects by key
Can load objects via indexes. This includes loading a single object and loading a range of objects.
Can create new database objects
Can save changes made to a database object
Can delete database objects
Note: Serverside multiplayer code running on the Player.IO cluster will always have full access rights to all tables, since it’s running in fully trusted environment.