Data store structure

Help and Feedback Scripting Support
#1

Helll there !

Thinking of datastructures may be tough sometimes, but I just thought of something.

Would this be possible?

  1. Have a single datastore for main player data.
  2. Reference the scope as the Player.UserId whenever doing GetDataStore() Start the key with the Player.UserId and use a / separator
  3. Access data as if they were “members” (I want to get the Inventory table, I just put this key : “Player.UserId/inventory”)

So, getting the ReserveAccessCode of a Player (for cross server teleportation) would look like

local Data = DS:GetDataStore("UserData")

Data:GetAsync(Player.UserId .. "/AccessCode")

(Example)

What are your thoughts on that so far?

#2

It would work, but it’s definitely not performant. Saving one table under a certain key is HUGELY more efficient than saving 1 table under a seperate key.

#3

Sorry, but I didn’t understand what you meant here. Can you elaborate?

#4

He’s saying that using keys like that to separate the data is wildly inefficient compared to just saving a Table directly, e.g.:

local Data = DS:GetDataStore("UserData")

Data:SetAsync(Player.UserId, {
    Inventory = {Slot1Data, Slot2Data, Slot3Data, }; -- etc.
    AccessCode2 = "SomeData";
    AccessCode3 = "SomeMoreData";
})
#5

Oh yes, of course it is !
I plan to have a few fields, the AccessCode, the PlayerData (table containing the player data such as first join datetime, usersettings, inventory, and lots of other information…)

I am clearly not wanting to get data all the time :sob:

I just wanted to know if that system was great. I saw plenty of examples where they were doing houses/UserId, inventories/UserId, …

And I’m quite unsatisfied of this system. I want to have UserId/... because it feels easier to manage (on first glance). I wanted to know if having such a data structure would cause problems in the future, as I do not want to be limited by the data structure I choose now.

EDIT: Of course, it goes against the relational aspect of SQL databases but hey, DataStore use more of a NoSQL approach, so the relational part isn’t necessarily present (sadly)

#6

Given the nature of DataStores, ideally you should want to get all the Player’s data at the same time – and cache it to a Table or something in your game for actual use.

But that’s besides the point. Looking at the DataStore documentation, those prefixes are actually the modern way of handling scopes! Personally I think this is a worse API than having the keys and scopes as fully separate values on the Lua side of things, but I digress.

Your usage of "UserID/Scope" is fine, and I agree that it has better aesthetics, but the / in that string has some actual syntactic meaning that affects how the data is actually stored under the hood! I have no idea what the performance differences would be if you flip the keys and the scopes, but the APIs (especially the List stuff!) is definitely simpler to use with the "Scope/UserID" ordering.

Looked into it a bit more and you should definitely not use UserIDs as your scopes! If you want the reversed ordering, I’d just make a wrapper function that has the arguments in your preferred order and builds the correctly formatted key from that.

#7

I actually thought of this use case and told myself it may not be a good idea. I will have to use scope/.../UserId sadly.

I do agree with you that the new scopes API looks quite… Odd (to say the least).

I would have loved if Datastores were actually different than what they are. I oddly find SQL easier with data organization than Datastores. I never liked dealing with them because of several factors (including data versioning, which I dealt with via table filling function & not metatables)

Thanks for the advise, I will try to organize everything so that everything makes sense. But that means the use of data getter functions will increase…

1 Like
#8

Also, the link you sent is about changing the scope when getting the datastore. I realized it would act like that, that’s why I changed it so that the UserId is in front for the key. But either way, gotta put data differently.

1 Like
#9

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