Suppose I have a table in which I have a column which is multi-valued, these values are primary key of another table, now I could normalize this by making it single-valued column and repeating the same row for each value that occurs to be in the column, but I guess this is so redundant, note that this column can have up to 100 values(which are foreign key derived from another table).
Now if I make it single-valued column then obviously my rows will be multiplied by the number of keys I take from the foreign table, what is the best practice to normalize this kind of scenario in the most optimized way?
Table-1(
pk,
column-1,
column-2)
Table-2(
pk,
column-1,
column-2,
FK(Table-1))
Here my FK can relate to more than one item of table-1
Related
I have a similarity matrix between two items and I want to store it as a table in a relational database. Thus, I want the table to have three fields; the id of the first item, the id of the second item and the value of their similarity.
I think about making the two id columns a composite primary key. But how can I ensure that given two items (x, y), the composite key (id_x, id_y) is the same as (id_y, id_x) so I don't have duplicate entries?
Assuming your id values are using a data type that is well-ordered, one of the simplest ways to achieve this is to enforce a CHECK constraint such that id_x is less than id_y.
This may present some difficulties if you do not have a way to enforce this ordering before entries are created. Some databases allow computation within index definitions, in which case you may be able to define your index on (MIN(id_x,id_y),MAX(id_x,id_y)) and omit the CHECK. (For something like SQL Server, you can put such a computation into an indexed view definition)
I got this composite primary key in Table 1:
Table 1: Applicant
CreationDate PK
FamilyId PK
MemberId PK
I need to create a foreign key in Table 2 to reference this composite key. But i do not want to create three fields in Table 2 but to concatenate them in a single field.
Table 2: Sales
SalesId int,
ApplicantId -- This should be "CreationDate-FamilyId-MemberId"
What are the possible ways to achieve this ?
Note: I know i can create another field in Table 1 with the three columns concatenation but then i will have redundant info
What you're asking for is tantamount to saying "I want to treat three pieces of information as one piece of information without explicitly making it one piece of information". Which is to say that it's not possible.
That said, there are ways to make happen what you want to happen
Create a surrogate key (i.e. identity column) and use that as the FK reference
Create a computed column that is the concatenation of the three columns and use that as the FK reference
All else being equal (ease of implementation, politics, etc), I'd prefer the first. What you have is really a natural key and doesn't make a good PK if it's going to be referenced externally. Which isn't to say that you can't enforce uniqueness with a unique key; you can and should.
I have a table with some data summary which consist of client_id, location_id, category_id and summary columns. Values of the three id's columns are not unique.
At the moment I have created a composite key from client_id, location_id, category_id using primary keys. Those three columns will uniquely identify rows.
My question is, if I still should include unique primary key for that table for example column with auto-increment id ?
That depends completely on your uses of the table. If you don't want to refer to a given row in a query (for example, having a dependent table), the separate PK is unnecessary (eg. if you always ask for statistics for a given client and a given location and a given category). However, if you do have dependent tables, you probably want a separate PK as well.
If your composite key is the primary clustered index then I would say it's not necessary.
I have a Country table which includes the columns ID, Name and Code. All three of these columns should contain unique values and cannot be NULL.
My question is, would I be better to create a primary key on the ID column and a unique constraint for the Name and Code columns (in one index, I guess), or would it be better to just include the Name and Code columns in the primary key with the ID? And why? Are there potential downsides or complexities that will result from having a multiple-column primary key?
First of all - yes, a compound primary key made up of three columns makes it more annoying to join to this table - any other table wanting to join to the Country table will also have to have all three columns to establish the join.
And more importantly - it's NOT the same restriction!
If you have the PK on ID and a unique constraint on both Code and Name separately, then this is NOT valid:
ID Code Name
--------------------------
41 CH Switzerland
341 CH Liechtenstein
555 LIE Liechtenstein
because the Code of CH and the Name of Liechtenstein both appear twice.
But if you have a single PK on all three columns together - then this is valid because each row has a different tuple of data - (41, CH, Switzerland) is not the same as (341, CH, Liechtenstein) and therefore, those two rows are admissible.
If you put the PK on all three columns at once, then the uniqueness only extends to the whole tuple (all three columns) - each column separately can have "duplicates".
So it really boils down to
what you really need (which uniqueness)
how easy you want to make it to join to this table
I have column having name id in my table. id is the primary key in table. I want to know that is it necessary to have separate column for id as it is primary key in my table.
Not necessary to have a separate column, you could have an existing column as primary key if it can identify each record uniquely..
Any field or combination of fields can be a primary key if:
The values in those fields are always non-null.
The records with values in those fields are unique.
Those fields are immutable. That is, you won't change the values of those fields
after the record is created.
It's always better to keep things simple. If you already have a column that identifies the record it's just fine - don't add a new one.
There is also something called composite primary keys. You can use it if a combination of 2 or more columns always creates a unique sequence. Than you don't really need the 'Id' column. The truth though is some frameworks don't like this approach.
In your case the column you already have should be sufficient.
The PRIMARY KEY constraint uniquely identifies each record in a database table and if your table already contain that column then u don't need to add another column.