I was wondering if it would be better to have things like perishable_token (used for account validation and resetting of passwords), banned (boolean to check if the user is banned), email_verified (boolean to check if user's email has been verified) in a separate table in the database, as it will rarely ever be used.
Also, I have my applications set so that a user logs in with a password and email address. The email address will only ever be displayed on the User Edit page, and the password will never be displayed anywhere. As these two things will pretty much only be used when the user logs into their account, is it necessary to have them in the main User table in the database? Or would it be better (faster?) to have them in another table?
The user table will have -many- other things that will be displayed on all pages and will need to be checked often (things such as a user's "money" "credits/points" "logged_in?" "badges" etc).
Since your user table has many other things, it seems unlikely that you would get any performance improvement by moving those five columns (which seem not to contain much data) into a separate table.
Related
I have an application in which I register a user using only their email and password. Then later on, they fill in their profile, which includes their personal information such as numbers, address, the hours they work during the week, etc.
I'm confused now whether to store all that data in the same table or to have the following:
users (for authentication), persons (for the profile), address (for um, addresses), numbers (you get the gist).
I would like to know a DBA's input on this. How would you design this database for a userbase of 500 people, give or take. Are there going to be problems in the long run if I keep all the fields - around 30 right now - in the same table?
It is a good idea to separate site-used data from invoicing data.
When you are displaying a homepage after your user logs in, you usually want to display username and avatar. Also, you use email and other account info to log in. That is probably some stuff you want to keep handy all the time. Move it into one table then.
Addresses (invoice, delivery, etc.) and phone numbers are usually stored separately, as you only need those when placing an order.
Rule of thumb: keep column count under 30, read as few tables as possible. Of course you should design properly (never mix entities, etc.), but this rule is a simple check that you are not creating something awful.
I have read many posts and articles that state quite clearly that for the best in worst-case damage limitation, MySQL accounts should only be able to do what they're intended to do, and nothing else. This makes perfect sense and so there would be a connection account to my Database that does all the SELECTing of data, and another account that does UPDATE and INSERT activities, so that if someone does get the compromise by SELECTing data they shouldn't, then they can't quite as easily then UPDATE that data or INSERT etc.
You get the idea.
But, I have various Databases and use accounts to read/SELECT data and the this is output to the client page, but often these accounts will need to be updated, small things such as updating when a (website) user logs into their account, or updating some sort of hitcounter or other minor feature. Given the ringfencing of concerns outlined above, I feel it's a bit like using a flood to put out a campfire, to allow UPDATEing (etc.) to a privileged MySQL connection simply to say that user Bob logged in last at 4:10pm.
I have been digging on the web for suitable guides, blog posts and articles about how to best structure using multiple MySQL privileged accounts to complete the nessecary work with as minimum a risk of excess privilege as possible, but I have found nothing that has been much use, (mostly because of my wording seems to be attracting articles about setting up website users, or other topics associated with these keywords :-/ )
I have a few ideas on current approach and wanted a bit of feedback on the best method for doing activities as described in paragraph 2, typically 95% SELECTing, and a few specific instances of UPDATEing, or if any of the following are possible (or on flipside, are very bad ideas)? :
I currently have seperate PHP connection objects for each connection privilege user. Is this the best approach?
Could I somehow giving a privilege user access to only update a certain table (or even a certain table column?), as well as SELECT from any table? This would be perfect.
Are using TRIGGERs a common approach and would this have any down sides if I created a Trigger (with a privileged user) and then let a SELECT user account access triggers?
Could I set certain users can only use certain triggers?
Is there another way of doing this?
MySQL allows for users to have different privileges set both at database and individual table levels. The documentation on the GRANT (http://dev.mysql.com/doc/refman/5.7/en/grant.html) syntax gives an example of setting all privileges to a user on one database while only select access to a table in another database.
Privileges can even be set for specific columns (http://dev.mysql.com/doc/refman/5.7/en/grant.html#grant-column-privileges) in a table & also for stored procedures (http://dev.mysql.com/doc/refman/5.7/en/grant.html#grant-routine-privileges).
I am doing the design of a database, that will have eventually thousands of users. Each user has your profile and specific data associated.
In your opinion, it is best practice a table for id, username, activationLink and hash and another for address, age, photo, job, or it is best a unique table for all stuff?
thanks for your time
If:
All (or almost all) users have all data filled
Most of the time you query for all fields
then keep them in a single table, otherwies split them.
In your model, activationLink seems to be queried for only once per activation, so I'd move it into a separate table (which would allow deleting it after the account had been activated).
Address, age, photo and job are usually shown along with the username, so it would be better to merge them into a single table.
Don't allow your initial design to limit the ability (or just make it difficult) to expand your requirements in the future.
At the moment, a user may have one address so you might put it in the users table - what if you want them to be able to store "work" and "home" addresses in future, or a history of past addresses?
A user may only be allowed to have a single photo, but if you put it (or a URL for it) in users.photo, then you'd have to change your data structure to allow a user to have a history of profile photos
As Quassnoi mentions, there are performance implications for each of these decisions - more tables means more complexity, and more potential for slow queries. Don't create new tables for the sake of it, but consider your data model carefully as it quickly becomes very hard to change it.
Any values that are a strict 1-to-1 relationship with a user entity, and are unlikely to ever change and require a history for (date of birth is a good example) should go in the table with the core definition. Any potential 1-to-many relationships (even if they aren't right now) are good candidates for their own tables.
I've a problem deciding where to place a certain table field within my database.
The database is for a classified ads website.
I want registered and non-registered users to be able to post ads. If an unregistered user posts an ad, the site should ask him for the contact phone, if the user is already registered, then the contact phone stored in the users' table should be used.
Now my question is, would it be possible to store the contact phone for both registered and unregistered users in the same table field?
If so, where should that field be put, in the Classified ads table, or in the users' table (noting that each user within the table has a unique Id, thus, filling the users' table with unregistered users just to get their contact phone will just fill the table with useless data)
Thanks in advance !
well you can put the phone field in the ads table, with a is_registered field inside. Then via php you check is_registered and then you know where to search for phone number.
Regards
You can store unregistered users' phone numbers in the same column of the same table, and you probably should. It makes the transition from unregistered user to registered user dead simple--you don't have to move or re-enter phone numbers. And if any user changes phone numbers, it only has to be updated in one place. (Do you know how many people accidentally drop their cell phones in a toilet every day? It's staggering.)
If you're now relying on the presence of a phone number to identify registered users, you'll need to fix that first. (I don't think you're doing that, but if you are, fix that first.)
You said
filling the users' table with
unregistered users just to get their
contact phone will just fill the table
with useless data
If it's useless, don't store it. If you need to store it, it's not useless.
You can always delete unregistered users when their classified ad terminates. But . . .
Does it make sense to require a contact phone number instead letting the user choose to leave either a phone number or an email address? Personally, I prefer to use a throw-away email address for things like this.
I would look for flexibility in your design, but if your logic treats users mostly independently of whether they are registered or not, I would use the same table and just complete the rest of the user's data for the registered ones. I wouldn't store user data on the ads table, even if only for clarity of data organization.
I guess your registered users will all have a username and password, so you can just check the presence of these to know if they are registered or not. If you don't want to change your logic in the future you should choose this distinction carefully of course.
A different approach: Why not making registration so easy that it makes no sense to have unregistered users? I you are already asking for a phone number in all cases, just add a password field or generate one automatically and you have all your users registered.
I would ask for an email so you can send the password and perhaps ask for account verification (now or in the future).
I'm currently working on a game, and just a while ago i started getting start on loading and saving.
I've been thinking, but i really can't decide, since I'm not sure which would be more efficient.
My first option:
When a user registers, only the one record is inserted (into 'characters' table). When the user tries to login, and after he/she has done so successfully, the server will try loading all information from the user (which is separate across multiple tables, and combines via mysql 'LEFT JOIN'), it'll run though all the information it has and apply them to the entity instance, if it runs into a NULL (which means the information isn't in the database yet) it'll automatically use a default value.
At saving, it'll insert or update, so that any defaults that have been generated at loading will be saved now.
My second option:
Simply insert all the required rows at registration (rows are inserted when from website when the registration is finished).
Downsides to first option: useless checks if the user has logged in once already, since all the tables will be generated after first login.
Upsides to first option: if any records from tables are deleted, it would insert default data instead of kicking player off saying it's character information is damaged/lost.
Downsides to second option: it could waste a bit of memory, since all tables are inserted at registration, and there could be spamming bots, and people who don't even manage to get online.
Upsides to first option: We don't have to check for anything in the server.
I also noted that the first option may screw up any search systems (via admincp, if we try looking a specific users).
I would go with the second option, add default rows to your user account, and flag the main user table as incomplete. This will maintain data integrity across your database, whereas every user record is complete in it's entirety. If you need to remove the record, you can simply add a cascading delete script to clean house.
Also, I wouldn't develop your data schema based off of malacious bots creating accounts. If you are concerned about the integrity of your user accounts, add some sort of data validation into your solution or an automated clean-house script to clear out incomplete accounts once the meet a certain criteria, i.e. the date created meeting a certain threshold.
You mention that there's multiple tables of data for each user, with some that can have a default value if none exist in the table. I'm guessing this is set up something like a main "characters" table, with username, password, and email, and a separate table for something like "favorite shortcuts around the site", and if they haven't specified personal preferences, it defaults to a basic list of "profile, games list, games by category" etc.
Then the question becomes when registering, should an explicit copy of the favorite shortcuts default be added for that user, or have the null value default to a default list?
I'd suggest that it depends on the nature of the auxiliary data tables; specifically the default value for those tables. How often would the defaults change? If the default changes often, a setup like your first option would result in users with only a 'basic' entry would frequently get new auxiliary data, while those that did specify their own entries would keep their preferences. Using your second option, if the default changed, in order to keep users updated, a search/replace would have to be done to change entries that were the old default to the new default.
The other suggestion is to take another look at your database structure. You don't mention that your current table layout is set in stone; is there a way to not have all the LEFT JOIN tables, and have just one 'characters' table?