Good evening guys, I hope you all are well. I'm from latin america, so I hope you excuse my writing.
I have a database with 3 tables:
tenant (the users)
company (the user's companies)
company_x_tenant (which is generated by the relation many-to-many that tenant and company have)
so company_x_tenant has foreign keys (that are the primary keys that company and tenant have).
I'm trying to insert data into company_x_tenant table, but it's not allowed until I insert data into the tenant table and then the company table.
The problem is that I don't know if when I insert data into the company table, I should make a second insert to the company_x_tenant table. My boss says that the company_x_table exists because the website needs to prevent every user from deleting any company, so just one user can have complete access to it's own companies and delete or update them.
I hope I made myself clear :( Thank you!!
If only one user should be related to a company in this manner, there is no need for the company_x_tenant table; those are mostly for "many to many" relationships. Just put some "owner_user_id" field in the company table that is a foreign key to users.user_id.
Related
I have two table in my database first is shop_details and second one is shopOwner_login
in shop_details table there is column named
ShopOwner_email
Shop_Pass
and same in shopOwner_login table there is
ShopOwner_Id,
ShopOwner_email,
Shop_Pass
Now i want to make a form in which if user enter data in shop details table like shopowner Email and its password it will store on those two table automatically goes
Can i do this if yes please help me for it i also tried foreign key i am so confused with foreign key because i am new to php and MySql please help me.
Each of your table should have Primary key. Primary Key is the unique id (could be number or string or even uuid. Ex: ShopOwner_Id) which could be used to fetch any row in the table. This primary key is used to establish relationships between tables.
Also for relationships there could be 3 types of major relationships between two tables.
One to One
One to Many or Many to One
Many to Many
For example,
lets say you have two tables UserLogin and UserProfile. UserLogin contains -> id, email, password, and verified. Whereas UserProfile contains -> id name, address, mobile, dob, etc. Here Each UserLogin will have single UserProfile whereas each UserProfile will have only one UserLogin. So they have One to One relationship. In this case, You add the foreign key to the both tables. You will add profile_id as foreign key in UserLogin whereas login_id in UserProfile.
Lets say, you have two tables Shop and User. Where each Shop will belong to a single User (in your case shopowner) But a User can have multiple Shops. In this case, Shop and User have Many to One relationship (or User and Shop have One to Many relationship). In this case we add a foreign key of user_id (which is primary key of User table) to Shop table.
In your case I will suggest to only keep email and password in shopOwner_login table and add its foreign key to shop_details table. This way your data will be normalize and you will not have to make sure to maintain same data in multiple tables.
So,d query need to fetch the data looks like - SELECT a.ShopOwner_email Shop_Pass as EmailId,a.Shop_Pass as Password FROM shop_details as a left join shopOwner_login as b on b.ShopOwner_Id = a.ShopOwner_Id
I am working on a game where the user can register, has an inventory and has weapons in that inventory. I want to store this information in my database.
Here is how I have set it up so far:
My user table contains a UserID column (along with other information).
My inventory table contains an InventoryID column and a UserID column
(the UserID corresponds to the owner of the inventory)
My Weapons table contains an InventoryID column which references the
Inventory it belongs to.
Is this the standard way of doing things? Can I change my layout and make it simpler? It just seems a little tedious to work with databases like this.
It would be so much easier if my User table had a reference to an inventory entry and that entry had an array of weapons. I've achieved this by storing references to the ID's of each entry but I can't just create a "User" php class (which has a reference to an Inventory object, which has an array of Weapon objects) by running one query to the database.
Maybe there is a framework to achieve this?
What You described is simple one-to-many relationship.
You don't need inventory table.
You need a user table with userID as primary key and use it as a foreign key in weapons table.
With help of joins You can use one query to get all records.
Have you considered a NoSQL database? :)
Relational databases often require "join" tables as you describe. You can probably accomplish this without a join table if user to inventory is 1:1 - and 1 weapon can only belong to 1 inventory/user - just have weapons store a user ID.
I want to design a DB which will be connected to PHP Application. In the app there are two types of users: company and person. Some functionality like adding articles will be done by both so in other tables there are author_id columns. So firstly I decided to create user column.
That's easy: id, username, password, role, active, created where role defines whether user is person or company.
Now I want to add profile table or profile tables depends on what you'd suggest (joined with the previous table by adding profile_id column there).
Both roles have different fields, which are required during registration.
The easiest thing would be to create one table with all required fields for both roles, allow them NULL values and in the PHP app (made in Yii Framework in this case) define requirements for each role in models.
The nicest thing would be to create separate tables for both roles BUT the questions is how to connect these two tables to one table using Foreign Key? Is it even possible. I know I may omit foreign key creation then based on role choose table, and from that table choose profile_id.
Or maybe you have another solution to my problem.
Thanks in advance for replies.
Adrian
You need an intermediary between the page and the database to assign the user to a group that has specific privileges. It's usually accomplished with a user-group-role design.
You can have a table for users system info (username , pass ...), and another for users profile (firstname , birthday ...), and another for groups(superuser , ...).
where user table can have multiple groups: user:one->group:many
user can have one profile user:one->profile:one
I think this is a decent solution.
I am trying to model a database for my current project and I came across a new problem. I have a Project which is supervised by Supervisor, Coordinator and Company. So Project table has Supervisor.id as foreign key and so on. There is also Student table which contains Project.is as a foreign key (because many users can do a project). This is how it is right now. What I would like to do is to have a User table containing a column named type which allows me to see what the role of that particular user is (also student). Even though the table will contain many NULL entries, I will have far less redundant code.
However, the main reason I want to have one User table is that I am using CakePHP and it is not easy to have different models log in. Is this possible in a nice way?
Thanks
EDIT: Maybe I should say that every one of these roles will have different permissions.
I see three tables: USER, GROUP, and ROLE.
Users would be assigned to groups, and groups given roles. I think you need three, not one.
And cardinality matters: I can see where a USER could be assigned to many GROUPS; a GROUP could have many USERS; a ROLE could be assigned to several GROUPS; and a GROUP could have many ROLES. There are many to many JOIN tables as well:
USER <-> USER_GROUP <-> GROUP <-> GROUP_ROLE <-> ROLE
This is normalized - nothing is repeated this way. USER, GROUP, and ROLE have primary keys. The JOIN table primary key is a composite of the two IDs in each row.
It depend on how you will use your associations.
Why not
For example: if you use relation to output data later and you sure, that you database scheme will not changed, than ... why not? your main targets: quality of code and speed of development, so, not matter how much columns with null you will have.
But
if you not sure in your requirements or plan to extend database scheme you can use two columns
supervisor_model
supervisor_id
which will store apropriate values: Company, 77 (I mean that 77 it's id of come Company )
Another approach
You can UUID for you supervisor_id so, it will be unique among several tables and you have not many NULL and extra columns.
i want my database to support one company haveing many users how can i do that? exampleusers table(UID,username,password)company table(CID,companyname,usersthatistheownerofthecompany) how can i do that? what should i do ? should i make an array in php like 1241,423,4123 *uid's that will be inserted on usersthatistheownerofthecompany row ? or is there any better idea ?
If you want each user to have one (and never more) company, you should have :
user table
uid
username
...
company_id
company table
company_id
company_name
...
Then, user.company_id would be a foreign key, that references company.company_id.
And, then, you store :
One line in user for each user
Referencing the id of the right company for that user
which is the company_id of the right line in the company table.
And one line for each company in company
There is no user's related information stored in the company table -- and as each user "points" to a company, a company can have several users.
Storing data as an array like you suggested is definitely not quite a good idea -- just not the way a relational database works.
If each user can have several companies, and each comparny can have several users, you'll have to add a third table (a join table), that will indicate, for each user(s), to which company(ies) they are attached to :
user table
uid
username
...
company table
company_id
company_name
...
user_company table
uid
company_id
In this situation, there is no user-related stuff in the company table, and there is no company-related stuff in the user table : the link between those is in the user_company table.
Of course, user_company.uid will be a foreign-key to user.uid ; and user_company.company_id will be a foreign-key to company.company_id.
There is a better idea - it's called a cross-table join. What you do is you create a third table, which contains two columns. In those two columns you store the primary key of the tables you're connecting to eachother.
The idea is that you're creating a relation between a company and a user. In a relational database, relations are indicated between tables by using foreign keys.
Of course, this only applies when you want to connect multiple users to multiple companies (an "M-N" relationship). If you want to connect multiple users to a single company, simply add a column for the company id to the user.
Any relational database is a good way to go. Have a look at MS SQL or MySQL.