I have 2 keys in a DB table,
Country
employee id
region
What is the ideal sequence of the primary keys? Which one will help SELECT run with better performance?
Related
I have 2 tables:
index(id, asset_id, name, source_id, country_id)
index_trade_data_daily(index_id, date, daily_return)
First approach (current, see the picture below): id from index table connected to index_id and date from index_trade_data_daily. As I know in one to many relationship primary key from one table should be connected to foreign key from another table. But in this kind of relation I have no foreign-key. It's look like one-to-one connection. Where pk in index_trade_data_daily consist from 2 fields. Is it correct?
in addition index_trade_data_daily have no id and it's confusing me.
The second approach is to add id to index_trade_data_daily. Generate one-to-many relationship with index table. And add unique constraints both to [index_id, date].
But in this case id has no sense.
Which approach is better ?
Index table looks fine but the other table should have its own ID for itself as well as the index_FK (foreign key) from the index table which is related to the index ID from the index table.
Note you may want to think about using better names for your tables as the name "index" is apart of a table structure.
Assuming that the EMP_SALARY_INFO table does not have any other relations apart from the EMPLOYEE table.
My question is there is no primary key for the EMP_SALARY_INFO table. There is only one foreign key. When I create entity instances for the EMP_SALARY_INFO table, my foreign key i.e., EMP_ID repeats. Is this valid or does it violate any relational database rule? If this repetition is a violation, would I have to create a unique id (primary key) for the EMP_SALARY_INFO table?
That is perfectly OK. I would call out that in your example there is a possibility of having duplicate date ranges for the same employee. For example, if a mistake is made during data entry you may have two different pay rates for the same date range. Now, this may be a valid scenario in your case, however if it’s not then consider creating a unique constraint on Emp_id, from_date and till_date.
Foreign key of a particular table is a primary key of the table its referring to. Hence, in your case above as long as you have data in your empid of employee and same data if referred from emp_salary_info wont cause any sort of problem even if it repeats in the emp_salary_info table as its not repeating in the table its referring to i.e. Employee
Sometimes, there are certain tables in an application with only one column in each of them. Data of records within the respective columns are unique. Examples are: a table for country names, a table for product names (up to 60 characters long, say), a table for company codes (3 characters long and determined by the user), a table for address types (say, billing, delivery), etc.
For tables like these, as the records are unique and not null, the only column can be used as the primary key, technically speaking.
So my question is, is it good enough to use that column as the primary key for the table? Or, is it still desirable to add another column (country_id, product_id, company_id, addresstype_id) as the primary key for the table? Why?
Thanks in advance for any advice.
there is always a debate between using surrogate keys and composite keys as primary key. using composite primary keys always introduces some complexity to your database design so to your application.
think that you have another table which is needed to have direct relationship between your resulting table (billing table). For the composite key scenario you need to have 4 columns in your related table in order to connect with the billing table. On the other hand, if you use surrogate keys, you will have one identity column (simplicity) and you can create unique constraint on (country_id, product_id, company_id, addresstype_id)
but it is hard to say this approach is better then the other one because they both have Pros and Cons.
You can check This for more information
I have read that all foreign keys should be indexed for better join performance. Do that mean, by definition, that all bridge tables should have all fields indexed
for example lets say i have 3 table
Project: Id, Name
ProjectApplication: Id, ProjectId, ApplicationId
Application: Id, Name
in these cases, should ProjectId and ApplicationId both have indexes on them?
In your given example Id column in Project table have to be a Primary key(or atleast UNIQUE constraint) in order to be able to reference it in any other column i.e creating a foreign key constraint which references it same is true for Id column in Application table. So by default it will have a Clustered Index defined on it.
Now in your ProjectApplication table if you do create a foreign Key and create an Index on that column, and obviously when ever you need to retrieve information from these tables you will be joining these tables on these two fields so having a Clustered Index on one side and a nonclustered index on other side will most definitely have a great impact on the performance of your queries, well worth it , go for it .
I am fairly new to database design, for many to many relationship, what is the differences and implications of creating a composite key and a unique id for e.g.
Country table
CountryID
CountryName
Language table
LanguageID
LangugageName
Many to Many table - using composite:
CountryID Pkey
LanguageID Pkey
OR
Using unique Id:
AutoID Pkey
CountryID
LanguageID
Composite Key :
A composite key is a combination of more than one column to identify a unique row in a table.
composite key can be a primary key .
PRIMARY KEY
The PRIMARY KEY constraint uniquely identifies each record in a database table.
so its all depend on your requirement
in first design
Many to Many Table:
Using composite:
CountryID Pkey
LanguageID Pkey
if you use this desing than CountryID and LanguageID is composite primary key.i.e here
data of the table will be
CountryId LaguageID
1 1 //valid
1 2 //valid
1 3 //valid
1 1//not valid data as its form composite primary key
and in second design
Using Unique Id:
AutoID Pkey
CountryID
LanguageID
AutoID is become primary key so this will allow data lke thsi
AutoId CountryId LaguageID
1 1 1 //valid
2 1 2 //valid
3 1 3 //valid
4 1 1 //valid as AutoID is primary key
1 2 3 // invalid as AutoID is prinary key
hope this presentation help you to understand difference
what is the differences and implications of creating a composite key and a unique id for e.g.
You'll need to create a "natural" key on {CountryID, LanguageID} to avoid duplicated connections in any case. The only question is whether you'll also need a "surrogate" key on {AutoID}?
Reasons for a surrogate key:
There are child tables that reference this junction table (and you'd like to keep their FKs slim or prevent ON CASCADE UPDATE propagation).
You are using an ORM that likes simple PKs.
Unless some of these reasons apply, use only the natural key.
BTW, under a DBMS that supports clustering, a natural key like this is usually a good candidate for a clustering key. If you cluster the table, every other index (such as the one underneath the surrogate key) has extra overhead (compared to an index in a heap-based table) since it needs to keep the copy of clustering key data and can cause a double-lookup.
See also: A column as primary key or two foreign keys as primary key.