This is for a multiplayer CCG game. User has data for obtained cards, username, user id, accumulated gold etc. while of course having authentication information like email, password, token etc.
I'm not sure if I should keep these data in separate tables because I don't see any cons for doing so but on the other hand it feels like they should be in separate tables.
Is there any pros/cons for these approaches?
and which approach would you use?
Related
I need help understanding the best approach to structure my firestore data.
I come from traditional SQL background and have a little bit of nosql mongodb background as well. I am building a small football prediction app and here is the user flow:
User:
User registers/signs in
They can pick a contest to join
Enter their predictions every week
Admin:
Create contests and add/edit games to contest every week (an api will fetch all the data like fixtures and results)
Set a deadline for when users can enter their last prediction for the game week
Other:
Leaderboard
Now I did create a diagram on how I would traditionally structure this data but it would be nice if someone can exaplain to me the simplest approach to structuring such an app in Firestore
It looks reasonable but I would be concerned about storing the passwords in Firestore DB. Firestore should not ideally be concerned with authentication. Check Firebase Authentication for different auth options with Firebase. You'll probably end up only having to store the user ID as other information is in the User object.
Also check out Supported data types. You probably want to change varchar(x) to (UTF-8) string or byte types. Moreover, there is a reference type so you could reference the actual user document from the other tables.
One main design will be whether to use nested collections (Hierarchical Data).
You might be able to nest score under competitions.
I am designing a Node + MySQL backend for a service that requires two-factor authentication to be set up for all users as a part of the sign-up process. Users first submit a primary phone number and password (with the phone number being used for sign-in), upon which the server sends them an SMS with a six-digit code. Only after they enter the code is their account fully created.
This poses the problem of how to store data for users in the intermediate state after entering username/password but before verifying the code. Such "pending users" will not be shown in searches, do not need to store all the data a regular user would, and will be deleted after a few days if never verified. Furthermore, since every user must enable TFA to fully sign up, there will be orders of magnitude more users than "pending users". Thus, it does not seem sensible to me to have all users simply store an "isVerified" flag. I am familiar with SQL on a technical level but have no experience designing databases for production, and I am wondering what alternate mechanisms I should consider to solve the aforementioned.
My current idea is to have a separate table of pending users, having only those columns necessary to store intermediate signup information. When a user verifies, a row is created in the real user table, the signup information is copied over, and the corresponding is row deleted from the pending users table. However, this makes it somewhat ugly to ensure that the primary phone numbers are unique across both tables (which is an additional requirement of the service).
What methods/techniques should I consider to improve my solution?
You can store this data same way as store session information on server.
currently I need to provide web site logging for different social accounts (facebook, google, twitter and so on).
I know that stackoverflow has same system and I wonder if there is stackoverflow database model in public access. So I can find right way to store user data in my db.
Currently I have next problems.
So, I have my table for users:
UserID
UserName
RegistrationDate
Email
Rating
For users who create account with web site form I use next additional info:
Password
FirstName
LastName
Avatar
I stock in question how to store data for users who login with social networks and what should I store.
It seems that I dont need to store facebook name, surname and so on. I thought about getting it with js on pages where I need it.
Also I am thinking how to provide user with adding facebook, twitter references and so on for his profile.
P.S.
I am using DotNetOpenAuth for user authentication via social networks. Working with asp.net MVC 3.
About functionality on my web site:
just adding articles and rating for user.
For comments I use https://disqus.com/.
Ideally, you should have two tables. One for Users and one for Identities. In the Users table, you store things like your application user id, name, emails, etc. In the Identities table, you link back to the person in the User's table, but have a 'network' field that says which network the Identities row is for (e.g. Facebook, Google, Twitter, etc).
The Identities table can store the User ID and details specific to that platform, e.g. User_ID for Facebook, Twitter username, etc. The user will have one entry in the Users table, but can have many entries in the Identities table, depending on how many networks the user has connected with.
We have a SL application and many users who use this system with different data and access roles. For example, each user can have some devices and each device will send its locations every 5 minutes to server.
One approach is defining a User table in database and have many tables which connect an entity to a user Id, but this is not a good idea as that creates many tables between users and other entities.
It will be a time consuming process to select user data or reporting, so I wanted to know what the best way is for handling such behavior in Silverlight?
You can use AuthenticationDomainService. This is a popular service for authorization users with roles. You can get more information there: http://msdn.microsoft.com/en-us/library/ee707361(v=VS.91).aspx
In my current application, I'd like to offer the possibilities for the users to connect them trough a password or any social network or open id platforms.
I'd also will post message on their wall (facebook, twitter, buzz mostly) if they link their accounts to my app.
The problem I face is how I can organize my tables in the database.
Here's how I would do, but without any convictions :
User(first_name, last_name, email)
LocalUser(password, user_id)
FacebookUser(token, user_id)
GoogleUser(token, user_id)
EtcUser(...)
If the user connect through Facebook, I will fill all the data in the User table I can, and then he will have the possibility to connect my app to other networks (like Google and Twitter).
But the problem of this implementation is if the user connect through Facebook one time, use the app without connecting to others social layers, and later, connect himself via Google, the app won't recognize it's the same person and will create a new account, from scratch.
Also, It's possible that the tables for the session (FacebookUser, GoogleUser, etc) and the tables for the linked accounts would be different (maybe the token to access the social network and the key to use the app is different ?)
I already have a session table like this one :
// Maybe I should add a new column for identifying from which type come the token (Local, Facebook, Google, etc)
Session(date, ip, token, user_id)
Do you think this method is good ? do you have a better one ?
Thank you ! very much !