Need a better way of doing this datastore

Help and Feedback Code Review
#1

I want to make a sort of virtual pet game, and specifically sava data of the dog you have. The problem is I want multiple dogs to be saved, but if I continue to do it this way it’ll be inefficient.

I’ve considered Table datastores but I’m not good at datastores in the first place, so I would need help for it. I would rather not use a datastore module thats not roblox, because last time I used a datastore module it stopped updating, and I had to recode the datastore.
I want an efficent way to save data for multiple dogs, ideally in a way where I don’t have to make a separate datastore for each dog.

local players = game:GetService("Players")

DataStoreService = game:GetService("DataStoreService")
local Runservice = game:GetService("RunService")

local Dog1DataStore = DataStoreService:GetDataStore("CashDataStore")


players.PlayerAdded:Connect(function(plr)
	
	local DogsFolder = Instance.new("Folder")
	DogsFolder.Name = "dogs"
	DogsFolder.Parent = plr
	
	-- dog 1
	local Dog1 = Instance.new("Folder")
	Dog1.Name = "Dog1"
	Dog1.Parent = DogsFolder
	local buyed = Instance.new("BoolValue")
	buyed.Name = "DogBuyed"
	buyed.Value = false
	buyed.Parent = Dog1
	local name = Instance.new("StringValue")
	name.Name = "DogName"
	name.Value = nil
	name.Parent = Dog1
	local skin = Instance.new("StringValue")
	skin.Name = "DogSkin"
	skin.Value = nil
	skin.Parent = Dog1
	
	wait(1)
	
	

	local dogdata = Dog1DataStore:GetAsync(plr.UserId)
	
	if dogdata then
		if buyed.Value == false then
			buyed.Value = true
			name.Value = "Hal"
			skin.Value = "White"
		end
	
	else
		
		print("No data")
		
		Dog1DataStore:SetAsync(plr.UserId, true)
	end

end)


players.PlayerRemoving:Connect(function(plr)
if not Runservice:IsStudio() then
	game:BindToClose(function()
		if game.Players:GetPlayers() <= 1 then return end
		local PlayerDog1 = plr.leaderstats:WaitForChild("Dog1")
	

		Dog1DataStore:SetAsync(plr.UserId, PlayerDog1.Value)
	
	end)
	end
end)
#2

First of all wrap your network calls in pcall because they can fail.

local success, dogdata = pcall(function()
    return Dog1DataStore:GetAsync(plr.UserId)
end

if not success then
  warn("error")
--errhndling
else
--code
end

or xpcall if you want to use a custom error handler.

Anyway, why are you using an entire data store just to store a bool value.
Why can’t you do something like this:

local dogs = DataStoreService:GetAsync("your datastore idk")

plr.PlayerAdded:Connect(function(plr)
      local success, result = pcall(function()
            return dogs:GetAsync(plr.UserId)
      end

       if not success then 
         plr:Kick("failed to load data")
       else
--[[assuming result is a table formatted like so
     [Dogname] = {
         [Skin] = skin,
         [Dogbuyed] = dogbuyed,
     }
--]]
          for name, dog in pairs(result) do
               local folder = Instance.new("Folder")
               folder.Name = name
               folder.Parent = plr

               local dogbuyed = Instance.new("DogBuyed")
               dogbuyed.Value = dog["DogBuyed"]
               dogbuyed.Parent = folder

--etc....
          end
      end
end)

It really depends on how you want to organize your data inside of the tables but this is a simple example of how you could store multiple dogs. Also why does dogbuyed exist? I’m assuming if the dog is saved to the player then they own the dog and have bought it, or is it used for something else?

#3

This.

Also, I’ve heard that ProfileService is a good utility to use instead of DataStoreService, as it has additional features, such as session locking (really useful to prevent duplication glitches). Session locking is essentially if a player joins a server, the datastore is only loaded once, and if by some miracle the player joins a different server at the same time, the datastore will not be loaded and the player will be kicked.

Also, If you’re looking to have mulitple datastores, e.g. Coins, Dogs or whatever, you could probably also just create a function with multiple parameters to shorten your code.

Or don’t. Up to you.