i have one product table
which have
product_id name price
and i want to store multiple images of single product here product_id is primary key and auto increment so how would store i store multiple images of single product.
one solution is define anothe table which has product_id as a foreign key
that is
product_id images
suppose i add
product_name moblie it id is auto incerment.....so how would i store the multiple images of this as i does not know what product_id is genertaed as it is auto increment?????
please help anyone????
Create a second table with a generated id, product_id (foreign key) and image_location or something.
Then you're there.
Consider a scenario where electronics is a main category and TV, fridge etc. are the sub categories, how you will a create db schema (table structure) for it using single table?
I would add a nullable column that reference the identity column of itself.
Eg:
CategoryID (primary key) NOT NULL
CategoryName NOT NULL
ParentCategoryID NULL reference CategoryID
Querying those type of hierarchical table is sometimes tricky, however you can create an unlimited levels of subcategories.
Use ENUM
CREATE TABLE electronics (
...
category ENUM("TV", "fridge", "etc"),
...
);
and if you need a multiple depth for categories:
CREATE TABLE electronics (
...
category ENUM("TV", "fridge", "etc"),
parent_category ENUM("TV", "fridge", "etc"),
...
);
I am using Access to create a database. I have two tables with the following data.
Car
CarID - PK
CarName
CarPrice
CustomerID
Customers
CustomerID -PK
Username
Password
CarID
I wish to have the relationship as many cars to one customer. Would I need a 3rd 'link' table or is there a way to do this without another table? Sorry for such a simple question
Remove CarID from your Customer table. Make CustomerID in the Car table a foreign key to Customer, and remove any existing unique constraints on that column.
Remove CarID from your customers table and you would be set. Just be sure to have the CustomerID field in the Car table be a Foreign Key.
I went through many threads and couldn't figure it out. Sorry if this is a duplicate question. Consider the following setup.
1) Employee => (ID,Name)
2) Department => (ID,Name,location,Clerk,Accountant,Middle-manager,Group-manager,Regional-manager,Active)
Department can have many Clerks, Accountants, Middle-managers and so on. They are just employees from the Employee table. Need a better database schema (flexible like, adding up a new column as Divisional-Manager must be easy) for Department entity with NO data duplication, NO update anomalies and NO / less junction tables.
Thanks in advance! :)
You need something like this;
CREATE TABLE department(
dept_id int NOT NULL,
dept_name char(10) NULL,
CONSTRAINT PK1 PRIMARY KEY NONCLUSTERED (dept_id)
)
go
CREATE TABLE department_employee(
id int NOT NULL,
dept_id int NOT NULL,
emp_id int NOT NULL,
CONSTRAINT PK3 PRIMARY KEY NONCLUSTERED (id)
)
go
CREATE TABLE employee(
emp_id int NOT NULL,
emp_name char(10) NULL,
CONSTRAINT PK2 PRIMARY KEY NONCLUSTERED (emp_id)
)
go
ALTER TABLE department_employee ADD CONSTRAINT Refdepartment1
FOREIGN KEY (dept_id)
REFERENCES department(dept_id)
go
ALTER TABLE department_employee ADD CONSTRAINT Refemployee2
FOREIGN KEY (emp_id)
REFERENCES employee(emp_id)
go
You have a many-to-many relationship so you need a third association (junction) table - you can't avoid it.
DepartmentMember => (DepartmentId, EmployeeId, MembershipRole)
Why don't you want this?
Employee =>(ID,name, department_ID, position_ID, Active)
Position =>(ID, name, Active)
Department => (ID,Name,location,Active)
Department =>(ID,employeeID,location,active)
Employee =>(EmployeeID,name, position)
I think that would be a much better way of organizing your tables. This assumes that active is a property of the department, else move it to the employee table.
Assuming an employee can only work in 1 department. IF not, then yes, you need a third table to avoid duplication
Employee
ID, Name, EmployeeType, DepartmentID
(pk on ID, EmployeeType)
Department
ID, Name, Active
Position/Title is very much contextual
to Department. One can be a
Regional-Manager in one department and
can additionally takes Consultant
position in another department.
Then , the department and the Employee is many-to-many. The Employee to the position is also many-to-many. If you need flexibility ,like adding a new title for a department , the junction tables are necessary. You cannot avoid it.
You can refer to the following Table structure for reference:
Employee
-----------------------
EmployeeID (PK)
EmployeeName
Active
Department
-------------------------
DepartmentID (PK)
DepartmenName
Location
Position
----------------------------
PositionID (PK)
PositionDescription (eg.Clerk, Accountant etc)
EmployeePosition
----------------------------
EmployeeID (FK to Employee.EmployeeID )
DepartmentID (FK to Department.DepartmentID)
PositionID (FK to Position.PositionID )
If the Position/Title is fixed to
Employee instead of Department.i.e. An
employee who is clerk and can be in
that position to one or many dept.,
how can we go about it?
Do you mean that in an extreme case , many employees can have their own special titles ? and they belong to many departments? If yes ,suppose a employee ID 123 has a special title called "The Special One" , and it belongs to the IT , Account and Sales department . You first create this title (i.e "The Special One" ) in the Position table and get the Position.PositionID.
Then you insert 3 records for Employee.EmployeeID 123 into EmployeePosition table using this Position.PositionID and the Department ID of IT , Account , Sales departments.
I want to store multiple translations of an text in a MSSQL database.
for example one table product with the columns
ProductId
ProductPrice
ProductNameId
primairy key = ProductId
and a table with the productnames
Id
Language
Name
primairy key = Id and Language
How can i create an foreign key to link the Product.ProductNameId to ProductName.Id
I think that the most appropriate pk-fk relationship is between ProductId on the Product table, and a ProductId (without Language) in the ProductName table. The field on the Product table is the pk, and the field in the ProductName table is the fk. That will ensure that there are no records in the PeoductName table that don't match with a record in the ProductName table.
If you want to treat Language similarly, then you can create a Language table with a LanguageId field. then, make a LanguageId field in the ProductNames table, and make that a fk.
when you retrieve product information, you JOIN Product and ProductName on their ProductId fields, and then specify the LanguageId in the WHERE clause.
I'd change the ProductNames table to:
Id
ProductId
Language
Name
With these constraints:
Primary key on Id
Foreign key on ProductId
Unique constraint on (ProductId,Language)