Is it good or bad to use multiple scopes to sort out datastores?

Help and Feedback Scripting Support
#1

So, instead of just saving everything like tools, currency, skins, etc in the single default scope is it better to seperate them using custom scopes?

Example:

local CoinStore = game:GetDataStore("Data", "CoinData")
local ToolStore = game:GetDataStore("Data", "ToolData")
local PlotStore = game;GetDataStore("Data", "PlotData")

Now this is nice to organize seperate data but what I’m worried about is since they’re all in the same datastore, when the player joins or leaves I will be calling setasync/getasync more times than I normally would with a default scope, is this bad for performance?

Example:

game.Players.PlayerAdded:Connect(function(player)
local success, coinData = pcall(function()
return CoinStore:GetAsync(player.PlayerUserId)
end)

local success, ToolData = pcall(function()
return ToolStore:GetAsync(player.PlayerUserId)
end)

local success, PlotData = pcall(function()
return PlotStore:GetAsync(player.PlayerUserId)
end)
end)

Or am I wrong and using multiple scopes is good?

2 Likes
#2

I’m basically in a choice between organization or performance

By the way I forgot the syntax of the userid is player.UserId because I wrote this stuff in a rush mb.

3 Likes
#3

It largely depends on the kind of data you’re saving - in this case, I recommend not doing it.

Scopes were pitched as a good way to categorize or organize your userdata, but as you mentioned, now developers have to call Get and Set more often, which has its own set of issues.

Nowadays scopes are really used more for sharding, but even then you can just spin up more datastores anyways.

If you’re not aware, sharding is basically splitting a set of data into shards for separate storage across datastores.
The goal is to mitigate the risk of hitting a size limit within your datastores - it’s akin to splitting your data into different sets so each datastore now stores less.

You could split up a player’s data so that their stats belong to one shard, and their PLOTS into another (considering that saving plots take up a lot of space), but really you shouldn’t do this for the sake of organization.

Besides, scopes are considered legacy. You probably shouldn’t use them for new work.

3 Likes
#4

Thanks for the answer, but quick question. If scopes are legacy? What is replacing them now?

2 Likes
#5

Prefixes. It works almost the same as scopes, but you don’t declare the scope when you initialize the datastore.

You instead specify a prefix to find keys for when you’re listing out the contents of a datastore.

So if you want to find all the keys that start with “player”, you can list all of them after specifying “player” as your prefix during the list call.

1 Like
#6

And this does not harm data limits or anything like that in any way?

Also could you show a small code sample of using prefixes? The sample on the documentation was sort of weird.

#7

Prefixes are only useful for LISTING keys.

You’ll still need to perform Get and Set to UPDATE those keys - this still has the same problem as scopes, it’s just more intuitive to use for organization.

Still, you probably might find little use with prefixes too. Don’t bother with organizing here, player UserIds are more than enough for organization.

#8

Oh, I don’t think I used prefixes for a leaderboard that I was making. Was this fine?

local Pages = datastore:ListKeysAsync()
	
	local Page = Pages:GetCurrentPage()
	
	for Every, Key in Page do
		local success, data = pcall(function()
			return datastore:GetAsync(Key.KeyName)
		end)
		
		if data and success then
			pcall(CopyData(Key, data))
		end
		
	end

I hope one day they help us organize keys more without being too hogging on resources.

#9

If you don’t specify a prefix to list keys of, you’ll just get every single key that exists. I can’t tell what that code is supposed to do, so I won’t comment on it further.

Also, organizing keys is a bit of a trap when it comes to datastores.

You know how you organize datastores? UserIds, a couple of datastores, and a bit of foresight. That’s more than enough for most cases.

1 Like
#10

It’s just to copy the data from the regular datastore to an orderedstore, you know for leaderboards.

#11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.