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)
Related
I am trying to create a SQL table to store a customer id and zipcode, only these 2 columns. Combination of these 2 values makes a row unique. I have 3 options in mind but not sure which one would be efficient. I will store around 200000 rows in this table and the read operation is high and write will happen once in a day.
Select query will get all customers based on the input zipcode.
example:
Select customerid from dbo.customerzipcode where zipcode in (<multiple zipcodes>)
Option 1:
Create a table with 2 columns (customerid and zipcode)
Create a composite primary key for these 2 columns.
Option 2:
Create a table with 3 columns (id, customerid and zipcode)
id being identity and primary key
create a unique constraint for customerid and zipcode
Option 3:
Create a table with 3 columns (id, customerid and zipcode)
Create a non clustered index for zipcode alone.
Can you please share which option would be better?
Select customerid from dbo.customerzipcode where zipcode in ()
The canonical design would have an index with each column as the leading column to support efficient lookup by zipcode or by customerid, eg
create table customerzipcode
(
zipcode varchar(10) not null,
customerid int not null references customer,
constraint pk_customerzipcode primary key (zipcode,customerid),
index ix_customerzip_customerid (customerid)
)
I have an entity table that I want to auto-generate data from to use as FK in other tables. The generated Id will become the PK in the other tables.
My Tables
Users table with user_Id (PK), and other columns such as firstname, lastname, email, password etc.
Entry table is the Entity table with one entry_Id (PK) column.
Article table will use the auto-generated entry_Id in Entry table above as PK with other columns such as title, authorId, category, created_Date.
Photo table will use the auto-generated entry_Id in Entry table above as PK with other columns such as title, imageurl, authorId (FK), created_Date.
Comment table will use comment_Id as PK with the auto-generated entry_Id in Entry table above as FK to form a composite key. Other columns include user_Id as FK from Users table, comment, created_Date.
Flag table will use flag_Id as PK with the auto-generated entry_Id in Entry table above as FK to form a composite key. Other columns include user_Id as FK from Users table, flag_type.
What I Want To Do
I want my query to auto-generate the entry_Id for entry when someone submit a form and automatically used the generated id in other tables such as Article, Photo, Comment and Flag.
When I hard coded the values, the Article and Photo table is accepting one entry_Id for multiple rows.
I saw something like this but I am not sure if it's what I want.
START TRANSACTION;
INSERT INTO foo (auto,text)
VALUES(NULL,'text');
INSERT INTO foo2 (id,text)
VALUES(LAST_INSERT_ID(),'text');
COMMIT TRANSACTION;
Is there a script I can use to make the auto-generated id in my entity table re-usable in other tables?
As commented by wildplasser, since version 9.1 Postgres has a nice feature that combines a cte with the returning keyword, which allows you to do what you want.
Here is an example based on your pseudo-code:
with foo_row as (insert into foo (text) values ('text') returning foo_id)
insert into foo2 (foo_id) select foo_id from foo_row
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 have a table that contains all products. There are 3 distinct types of products so these have their own tables, lets say ProductType1, ProductType2, ProductType3.
There is a 1-1 relationship between Products and ProductType(n) on ProductId, but to further constraint the child tables there is an additional relationship using a ProductId, ProductTypeId in Products, and a ProductId, ComputedProductTypeId in each of the other tables.
This ensures that a product can only be added to a single matching ProductType table.
The question is this. As there is already a relationship between the 2 tables on ProductId, rather than using an index for the FK, can I get away with a unique key to constrain the relationship, or will this cause performance issues?
Products
PK ProductId
FK ProductId, ProductTypeId
^
*Add an index for this or unique key constraint?*
ProductType(n)
PK ProductId
FK ProductID, ComputedProductTypeId (fixed int)
Creating an index will be better approach.
If you want to delete entries from your master table, SQL server looks for FK relations if any exists. So Creating Index on your composite key (which includes FK) will speed up the process.
If I have a primary key in table A and in table B of the same database (table B has its own primary key) I create a relationship with the primary key in table A so that a column in table B is the foreign key, does it mean that the primary key data created in the primary key column of table A will also be added to table B by virtue of it being a foreign key column or do I have to code that relationship, and if so how do I go about that?
In response to your question:
...do I have to code that
relationship, and if so how do I go
about that?
You will need to define the relationships between the two tables. Example:
ALTER TABLE tableB
ADD CONSTRAINT FK_tableB_TableA FOREIGN KEY (tableAId)
REFERENCES tableA (id) ;
When you insert a record into tableB you will still need to define tableAId is. SQL Server doesn't magically know what this should be.
So hypothetically if tableA looked like this:
1 | Some text | 1/1/2020
2 | blah blah | 6/1/2021
To insert a record in tableB that referenced record 2 you would need to do this:
INSERT INTO TableB (2,'My important information')
This assumes tableB has the following structure:
TableB
---------
Id --identity column/pk
tableAId --fk
SomeTextColumn
Your Q : does it mean that the primary key data created in the primary key column of table A will also be added to table B by virtue of it being a foreign key column
Nope, foriegn keys will not enter data into other tables. You will need a record in Table A before you insert a record referencing that foriegn key in Table B.
Q # 2 : or do I have to code that relationship, and if so how do I go about that?
insert into tableA, then insert into Table B. A trigger could be put on TableA to insert a record into TableB when data was entered into tableA had you wanted...
I'm not entirely sure what you're asking, but if you want to insert one record into table A and a related record into table B, then you have to specify the id from the table A record as the value in the foreign key field in table B.
Here's an example: table author has fields id and name.
INSERT author (id, name) VALUES (5, 'James Joyce')
Now table book has fields id, author_id and title.
INSERT book (id, author_id, title) VALUES(99, 5, 'Ulysses')
If the author's id field is automatically generated, then you would not specify it in the insert statement, and you would retrieve its value using the ##IDENTITY property.