I have a database with employees. the columns are first name, last name, department, internal number etc..
As for today it is a database only for one organization but in future i want to add to this database employees from other relative organizations.
What is the right way to do it:
To add another field to the first table ?
To create another table with 3 fields: id, organization_name, employees ( where in this filed i would put comma separated values of id from first table) ?
if the second answer will be chosen what will happened when an update query will be executed simultaneously from different accounts to the same organization. For example: i will be adding a user with id 55 to organization 'Police' and at the same time another administrator will be adding to the same organization a user with id 65..
In this case is there a possibility of error or data-loss ???
If someone had this kind of problem before, i really would like to read about it..
Thank You..
If the organization is only a number to group the users, then I would suggest to put them into the employees table. However if you have more information about the organization (e.g. name, address .. ) then make a new table for the organization and save the primary key of the corresponding organization in the employees-table.
Related
I created Users table.
After the user registered, The system enter his address, phone, city and more personal details to Users table.
There is another table, called Contacts, there the user add another people details.
Now, if there is Contacts table, How better to save the personal details of the user in Users table? in one json column that contains all the user personal details, or in normal columns (address, phone, city)?
I just do not want to happen a situation of multiple data.
I think separate columns for each field will be the better option!
Well, it would of course be easy to just store it as JSON, but that way, it could be a bit messy to search for certain stuff in the database (say you wish to check all users from a given city for example).
When it comes to user information, I always find the best way to do this is to store only login vital data and the base info in a users table.
Something like:
id | email | password
And then have different tables for the other data.
Name and such (which a user only has one of (of course one could have multiple names, but I usually only store first and last names)) could be stored in a user_information table, which is in a one to one relation with the user (foreign key for the user_id so that it can be quickly fetched when needed).
When it comes to address and phone number, a user could actually have multiple.
I understand that its possible that your system/app is only supposed to support one address or one phone number and the like, but its always nice to make it "right" from the start, so that its easy to just let the user add multiple of them whenever the need is there.
That way, you would have a few different tables:
users
user_information
addresses
phone_numbers
and so on...
The user_information, addresses and phone_numbers would preferably all have a user_id column which would be used for a foreign key to point at the user who owns it. And if you wish to make it possible to use the same tables for contacts, a contact_id could be added too (and a foreign key to point to the contact).
I'm new on programming, sorry if I can't explain my doubt very well...
My friend have a online game and I help him to manage it. The php has a table for the users (meh_users), and a table for the items that the users have (meh_users_items). Each item has a id, (column itemid) and also the users (column userid), and in the table of the items that the users have, there is a id for the combination of the user and the item. (just id, and sorry, I don't understand this so much).
There is an image, if this make more easy to understand me:
phpMyAdmin printscreen
I want to add an item (let's think that it's a sword and this item have the id 3454) to all the users, but I don't want to delete the other items that the users have. Also I don't want to insert the data on the table one by one, because it's more than a hundred users.
Hope I have said enough details!
Remember: I'm new and I already search soooo much in the internet before asking here.
I suppose you want to give that sword to all users, including ones that already have it. You don't need PHP for this, SQL is enought.
INSERT INTO meh_users_items (userid, itemid, equipped)
SELECT userid, 3454, 0
FROM meh_users
This is just an example. You need to add all field to SQL.
Three steps:
If it isn't there already, add the new item (e.g., the Sword of Power) to your meh_items table.
Get a list of all your users from the meh_user table.
Write a foreach statement creating an entry in the meh_users_items table for each user.
It also occurs to me that your database might have some setup issues. E.g., meh_users_items has a column indicating item type (e.g., weapon). That could end up being problematic. Better to keep that information with the items in the meh_items table.
So my question is very much just a database design question. I'm relatively new to PHP, taking my first database course, and I'm trying to figure out how best to execute my idea.
So I'm building a membership database. Within this database there are "members" and there are "meetings," represented as two separate tables. I'm wondering what might be the best way to add a list of members to a meeting instance, or create a relationship table between the two. For example, would you advise that each member ID (primary key) be added individually (say, via a bunch of text input form fields) when creating a new meeting instance? Or perhaps is there a way to easily have the user upload a CSV or excel file of primary key user id numbers and, from those user number ids, easily create a relationship table?
Hope this is clear- just hoping to get some advice/insight, perhaps I'm not aware of the easiest way... Thanks!
I don't know what are you trying to do in your particular case, but is sounds to me that you should have three tables:
members - you have that one already
meetings - you also have that one already
members_meetings: this one is the table, that will join the two tables. And the required fields in that table should be:
member_id - the id of particular member, points to the id field in your members table
meeting_id - the id of the meeting, this member is attending, points to the id field in the meetings table
Than, if you want to get all members, that are attending meating X, you can just run the following query:
SELECT members.* FROM members_meetings LEFT JOIN members ON members_meetings.member_id = members.id WHERE members_meetings.meeting_id=X
I have a table in database and there is column which contains multiple questions separated by commas(hockey,cooking,movies).
My question is that right now I'm firing a select query which is like this:-
$query="$sql="SELECT * from user where hobbies='$form_id'";
Actually in $form_id I'm passing the value say(games), now I want to display all the rows in the database which contains 'games'in them. Remember i have to compare this value with multiple values in the columns in that particulars of the database.
I'm using corephp with mysql as database. I really don't know how to do this please help me out.
SELECT * FROM user WHERE hobbies LIKE '%$form_id%';
but you should change your database schema like:
users(id, name, firstname, ...)
hobbies(id, name)
user_hobbies(id_user, id_hobby)
In reaction to John Conde's remark, the problem here is lying to your data model.
If a person can have several hobbies, you shouldn't store those hobbies in a field of the "person" table. Long story short, you should have 3 tables :
"Person" Table => Everything related to the person, and unique : name, birthdate, etc... NO HOBBIES !
"Hobbies" table => Everything related to the hobbies. The most simple form would be 2 fields : id & hobbyname. You could imagine adding more details in other fields, like is it an indoor or outdoor hobby, etc...
"PersonHobbies" table, used to link both : In that one, you'll probably have only 2 fields, 1 for the person id, one for the hobby id. Then if a person has 3 hobbies, you just write 3 records to that table with the same user id and a different hobby id
There are many advantages to this normalization. the biggest one is that it makes your queries easier to select but also update hobbies of a user. It also makes it easier to count how many hobbies each person has and so on. so, you SHOULD ALWAYS normalize your data, it doesn't take much more time when creating database and waves you a lot of time afterwards
I have working website in PHP with a MySQL backend which has several tables for different purposes.
This site is based on different parts or 'environments' like a bugtracker, project management, etc.
There is one central 'users' database which has all the users with the associated details in them.
In each of previously mentioned 'environments', which all have their own set of tables, it is possible to specify a user ID in certain fields.
e.g. the bugtracker table has a column called AssignedTo which contains the user ID's of users to whom bugs have been assigned.
The field type of these 'user ID' columns (like the AssignedTo example) is the same as the UserId field in the central users table, which is an unsigned, zerofilled INT(5) field.
Now I have a request from the users of this site to also allow to specify user groups in certain of these user ID fields.
So again reffering to the AssignedTo example, it should now be possible to also assigned a bug to a user group, instead of a specific user.
What's the best way to do this regarding the PHP scripting and the database layout?
Now I have all these fields set to the same type as the UserId of the central users table, which is INT(5).
However my UserGroupId field in the UserGroups table, is of a different format, INT(3).
I could make this field also into an INT(5) field, but that would not solve the 2nd issue I'm having: how to see whether the AssignedTo value is reffering to a specific user, or to a usergroup.
I was thinking about make the UserGroupId field start from 99999 and counting downwards, while the UserId field is starting from 00001 and counting upwards, thus assuming that if the AssignedTo starts with 9, it's reffering to a usergroup.
But this doesn't seem like a clean solution to me...
Any better ideas?
Thanks!
I think I understand what you are trying to say. I have a question. Can a user be in multiple UserGroups?
I would probably add a column in the bug table that says whether the AssignedTo value refers to a UserID or a UserGroupID.
Create a separate table for UserGroups.
If Users can belong to multiple groups, create an association table like: AssociationID, UserID, UserGroupID.
Otherwise if each user can only belong to one group, just add a UserGroupID column to the Users table
If I am understanding correctly, my solution would be to instead of having an AssignedTo column pointing to either a user or a user group, I would create two columns. One pointing to the user id and another pointing to a user group id.
Actually a colleague at work came up with the following solution which I really like:
Change the UserId and UserGroupId field types from INT(5) to INT(4). And leave the different fields like AssignedTo set to INT(5).
Now in the PHP code I can add a prefix number to either the 'UserId' or 'UserGroupId' value, this prefix number can be used to determine if the value is reffering to a UserId or a UserGroupId value.
So if the AssignedTo field is '10005' it means it's a 'user' with 'id: 0005'. Also to prevent having to update all existing records, values which have a '0' at the first position will be considered users
The advantage over using positive/negative values here is that in both the Users and UserGroups tables I can still use a positive 'Id' field which can be left to autoincrement. As far as I know auto-incrementing is not possible with negative values