Hi this article author wrote:
An IssueManagement can NOT exist without an Issue and as such seems to me well suited to using
So now why the foreign key from Issue table is not part of primary key in IssueManagement table?
This is because IssueMagement already have an autonumeric ID as primary key to make sure each row is unique.
Let me show you an example, but instead of number for ID I will use letters.
Isues Issue Magament
ID | IDM ID
A | X A
B | Y B
C | Z A
You only IDM to identify each Issue Magamentrow.
Related
This feels like a very basic question, but I really don't see the obvious answer at the moment.
I have a simple table that maps object ids between two namespaces:
|---------------------|------------------|
| id_in_ns1 | id_in_ns2 |
|---------------------|------------------|
| 1 | 5 |
|---------------------|------------------|
| 2 | 17 |
|---------------------|------------------|
| 3 | NULL |
|---------------------|------------------|
| NULL | 1 |
|---------------------|------------------|
The mapping is basically 1:1, but as you can see, some objects from namespace 1 do not exist in namespace 2, and vice versa, so that there are NULL values in the table.
So, what would be the primary key of this table? As a PK cannot be NULL, I can neither use (id_in_ns1) nor (id_in_ns2) nor the composite.
The only idea I have is to replace NULL by a definite value, say -1, and to use (id_in_ns1, id_in_ns2)as PK. However, this feels not only hackish but also "unnormal" because the non-NULL (or non--1)) value alone is already sufficient to uniquely identify an object.
Only add entries that have a valid id on both sides. This will effectively get rid of all NULL values, allowing you to specify a proper composite key on (id_in_ns1, id_in_ns2).
Ultimately, those are the values that allow you to identify a single row and you will not lose relevant information - a SELECT id_in_ns2 FROM mapping_table WHERE id_in_ns1 = x will return NULL either way, whether there is a (x, NULL) row or not.
If you insist on keeping those NULLs you could add another column with an artificial (auto incrementing) primary key, but that feels as hacky as using -1.
Use a synthetic primary key and use unique constraints for the rest:
create table mapping (
mappingId int auto_increment primary key, -- or whatever for your database
id_in_ns1 int references ns1(id),
id_in_ns2 int references ns2(id),
unique (id_in_ns1),
unique (id_in_ns2)
);
Just one caveat: some databases only allow one NULL value for UNIQUE constraints. You might need to use a filtered unique index instead (or some other mechanism) for this construct.
I wanna change the primary key in one table, but phalcon seems not offer any method to change the primary key.
uid is primary key in this table
+----+------------+------------+------+
| uid | name | type | year |
+----+------------+------------+------+
| 1 | Robotina | mechanical | 1972 |
| 2 | Astro Boy | mechanical | 1952 |
| 3 | Terminator | cyborg | 2029 |
+----+------------+------------+------+
$tmp = User::findFirst('uid = 100');
$tmp->uid = 900;
$tmp->rate = 15;
$result = $tmp->save();
these codes cannot modify anything in the table , but it return the $result is true, is it a bug?
I think it should offer a method to modify primary key.
I don't think it is a bug, I suspect that the Phalcon developers would subscribe to the principle of having primary keys as immutable or set in stone. See questions like : Can we update primary key values of a table? and https://softwareengineering.stackexchange.com/questions/8187/should-a-primary-key-be-immutable/
If anything the bug could be that Phalcon allows you to change the primary key in the first place.
Knowing why you would want to change the primary key might help, because I can't think of any reason off the top of my head why you would want to do that. I believe the main (only?) purpose of the primary key is to identify that row in the table, and any joining tables, whether Robotina has a uid of 1, 11 or 111 shouldn't really matter as long as the entry is unique for all rows in the table.
If the purpose of change is some kind of ranking like a leader board, I would suggest adding a rank field, as it will likely be more efficient that changing a special primary key field.
If you absolutely have to change the uid, I would be inclined to create a new row and delete the old one, if that sounds messy bear in mind that depending on which database you are using that might be what the database engine is doing behind the scenes anyway, and also that the very concept of editing a primary key would set a lot of people's teeth on edge.
Using CQL 3 I essentially want to make a statement like so....
SELECT * FROM columnFamilyName WHERE <PK>=1;
Where <PK> is a generic term for primary key.
If i have 2 tables one where the primary key name is ID, and one where it is Index, the above statement should work for both.
In a sense aerospike supports this(the primary key in aerospike simply doesnt have a name), but im not sure how to get the same generic primary key name in cassandra.
Ukemi, I'm not aware of this being possible because a Cassandra table can have a compound primary key and the first part of the primary key can also itself be a compound partition key.
E.g. in this situation:
CREATE TABLE .... PRIMARY KEY ((a, b), c, d) ..
Does <PK> refer to a, b, c or d?
Of course, if it IS possible, I'd like to know too!
Cheers,
CQL does not have a generic term for the primary key; instead you would need to provide it explicitly. Presumably an application or script which is reading from Cassandra would already have knowledge of the schema and would therefore know the key names.
However if you wanted to get the primary key column name(s) programmatically, here's one approach: use the Cassandra system tables to query the table definitions, and parse through the results to pick out the key name(s).
For example here's a simple table with a simple primary key (partition key):
cqlsh:key1> create table table1 (a int, b int, c int, primary key (a));
cqlsh:key1> select column_name,component_index,type from system.schema_columns
... where keyspace_name='key1' and columnfamily_name='table1';
column_name | component_index | type
-------------+-----------------+---------------
a | null | partition_key
b | 0 | regular
c | 0 | regular
And here's a slightly more complicated primary key like #reggoodwin suggested:
cqlsh:key1> create table table2 (a int, b int, c int, d int, e int,
... primary key ((a, b), c, d));
cqlsh:key1> select column_name,component_index,type from system.schema_columns
... where keyspace_name='key1' and columnfamily_name='table1';
column_name | component_index | type
-------------+-----------------+----------------
a | 0 | partition_key
b | 1 | partition_key
c | 0 | clustering_key
d | 1 | clustering_key
e | 2 | regular
For more information, check out the docs page on Querying a system table.
I just think that the answer is false because the foreign key doesn't have uniqueness property.
But some people said that it can be in case of self joining the table.
I am new to SQL. If its true please explain how and why?
Employee table
| e_id | e_name | e_sala | d_id |
|---- |------- |----- |--------|
| 1 | Tom | 50K | A |
| 2 | Billy | 15K | A |
| 3 | Bucky | 15K | B |
department table
| d_id | d_name |
|---- |------- |
| A | XXX |
| B | YYY |
Now, d_id is foreign key so how it can be a primary key. And explain something about join. What is its use?
I think the question is a bit confusing.
If you mean "can foreign key 'refer' to a primary key in the same table?", the answer is a firm yes as some replied. For example, in an employee table, a row for an employee may have a column for storing manager's employee number where the manager is also an employee and hence will have a row in the table like a row of any other employee.
If you mean "can column(or set of columns) be a primary key as well as a foreign key in the same table?", the answer, in my view, is a no; it seems meaningless. However, the following definition succeeds in SQL Server!
create table t1(c1 int not null primary key foreign key references t1(c1))
But I think it is meaningless to have such a constraint unless somebody comes up with a practical example.
AmanS, in your example d_id in no circumstance can be a primary key in Employee table. A table can have only one primary key. I hope this clears your doubt. d_id is/can be a primary key only in department table.
This may be a good explanation example
CREATE TABLE employees (
id INTEGER NOT NULL PRIMARY KEY,
managerId INTEGER REFERENCES employees(id),
name VARCHAR(30) NOT NULL
);
INSERT INTO employees(id, managerId, name) VALUES(1, NULL, 'John');
INSERT INTO employees(id, managerId, name) VALUES(2, 1, 'Mike');
-- Explanation:
-- In this example.
-- John is Mike's manager. Mike does not manage anyone.
-- Mike is the only employee who does not manage anyone.
Sure, why not? Let's say you have a Person table, with id, name, age, and parent_id, where parent_id is a foreign key to the same table. You wouldn't need to normalize the Person table to Parent and Child tables, that would be overkill.
Person
| id | name | age | parent_id |
|----|-------|-----|-----------|
| 1 | Tom | 50 | null |
| 2 | Billy | 15 | 1 |
Something like this.
I suppose to maintain consistency, there would need to be at least 1 null value for parent_id, though. The one "alpha male" row.
EDIT: As the comments show, Sam found a good reason not to do this. It seems that in MySQL when you attempt to make edits to the primary key, even if you specify CASCADE ON UPDATE it won’t propagate the edit properly. Although primary keys are (usually) off-limits to editing in production, it is nevertheless a limitation not to be ignored. Thus I change my answer to:- you should probably avoid this practice unless you have pretty tight control over the production system (and can guarantee no one will implement a control that edits the PKs). I haven't tested it outside of MySQL.
Eg: n sub-category level for categories .Below table primary-key id is referred by foreign-key sub_category_id
A good example of using ids of other rows in the same table as foreign keys is nested lists.
Deleting a row that has children (i.e., rows, which refer to parent's id), which also have children (i.e., referencing ids of children) will delete a cascade of rows.
This will save a lot of pain (and a lot of code of what to do with orphans - i.e., rows, that refer to non-existing ids).
Other answers have given clear enough examples of a record referencing another record in the same table.
There are even valid use cases for a record referencing itself in the same table. For example, a point of sale system accepting many tenders may need to know which tender to use for change when the payment is not the exact value of the sale. For many tenders that's the same tender, for others that's domestic cash, for yet other tenders, no form of change is allowed.
All this can be pretty elegantly represented with a single tender attribute which is a foreign key referencing the primary key of the same table, and whose values sometimes match the respective primary key of same record. In this example, the absence of value (also known as NULL value) might be needed to represent an unrelated meaning: this tender can only be used at its full value.
Popular relational database management systems support this use case smoothly.
Take-aways:
When inserting a record, the foreign key reference is verified to be present after the insert, rather than before the insert.
When inserting multiple records with a single statement, the order in which the records are inserted matters. The constraints are checked for each record separately.
Certain other data patterns, such as those involving circular dependences on record level going through two or more tables, cannot be purely inserted at all, or at least not with all the foreign keys enabled, and they have to be established using a combination of inserts and updates (if they are truly necessary).
Adding to the answer by #mysagar the way to do the same in MySQL is demonstrated below -
CREATE TABLE t1 (
-> c1 INT NOT NULL,
-> PRIMARY KEY (c1),
-> CONSTRAINT fk FOREIGN KEY (c1)
-> REFERENCES t1 (c1)
-> ON UPDATE RESTRICT
-> ON DELETE RESTRICT
-> );
would give error -
ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint 'fk' in the referenced table 't1'
The correct way to do it is -
CREATE TABLE t1 (
-> c1 INT NOT NULL,
-> PRIMARY KEY (c1),
-> KEY i (c1),
-> CONSTRAINT fk FOREIGN KEY (c1)
-> REFERENCES t1 (c1)
-> ON UPDATE RESTRICT
-> ON DELETE RESTRICT
-> );
One practical utility I can think of is a quick-fix to ensure that after a value is entered in the PRIMARY KEY column, it can neither be updated, nor deleted.
For example, over here let's populate table t1 -
INSERT INTO t1 (c1) VALUES
-> (1),
-> (2),
-> (3),
-> (4),
-> (5);
SELECT * FROM t1;
+----+
| c1 |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+----+
Now, let's try updating row1 -
UPDATE t1
-> SET c1 = 6 WHERE c1 = 1;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`constraints`.`t1`, CONSTRAINT `fk` FOREIGN KEY (`c1`) REFERENCES `t1` (`c1`) ON DELETE RESTRICT ON UPDATE RESTRICT)
Now, let's try deleting row1 -
DELETE FROM t1
-> WHERE c1 = 1;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`constraints`.`t1`, CONSTRAINT `fk` FOREIGN KEY (`c1`) REFERENCES `t1` (`c1`) ON DELETE RESTRICT ON UPDATE RESTRICT)
I understand the value of primary keys.
I understand the value of indexes.
Should every MySQL table have an auto-incremented primary key (ideally with INT field type)?
Update
#Raj More's answer seems most efficient. The issue when I think about it, however, is how this auto-incremented primary key ID will relate to other tables. For example:
table 1
ID | firstname | lastname | email
----------------------------------------
1 | john | doe | 1#email.com
2 | sarah | stow | 2#email.com
3 | mike | bro | 3#email.com
table 2
ID | memberid | display | address
--------------------------------------------
1 | 1 | funtime zone | 123 street
2 | 3 | silly place llc | 944 villa dr
In the example above, a consumer may come to the site and choose to register for a free product/service. If the consumer chooses, they are able to give additional information (stored in table 2) for additional mailing, etc. The problem I see is in how these tables relate to the 'primary key auto-incremented field'. In table 2, the 'memberid' relates to table 1's ID but this is not 'extremely' clear. Any new information placed into table 2 will increment by 1 whereas not all consumers will choose to participate in the table 2 required data.
I am not a huge fan of surrogate keys. I have yet to see a scenario where I would prefer to use one for every table of a database.
I would say No.
Read up on this answer: surrogate-vs-natural-business-keys
The above may be seen as sarcastic or flaming (despite the surprisingly many upvotes) so it's deleted.
In the general case, there have been many questions and answers on surrogate and natural keys so I felt this question is more like a duplicate. My view is that surrogate keys are fine and very useful, mainly because natural keys can lead to very big primary keys in the low end of a chain of connected tables - and this is not handled well by many RDBMS, clustered indexes get big, etc. But saying that "every MySQL table should have an auto-incremented primary key" is a very absolute statement and I think there are cases when they really offer little or nothing.
Since the OP updated the question, I'll try to comment on that specific topic.
I think this is exactly a case where an autoincrementing primary key is not only useless but adds negative value. Supposing that table1 and table2 are in 1:1 relationship, the memberid can be both the Primary Key and a Foreign Key to table1.
Adding an autoincrementing id column adds one index and if it's a clustered one (like InnoDB PK indexes) increases the size of the memberid index. Even more, if you have such an auto-incrementing id, some JOIN of table2 to other tables will have to be done using this id (the JOINs to tables in 1:n relation to table2) and some using memberid (the JOINs to tables in 1:n relation to table1). If you only have memberid both these types of JOINs can be
done using memberid.
I am a huge fan of surrogate keys. I have yet to see a scenario where I would prefer not use one.
I would say Yes.
Read up on this answer Surrogate vs. natural/business keys
Edit
I will change my answer to include the following:
There are certain scenarios that I now use the actual value as a surrogate key:
DimDate (20151031, 20151101, 20151102....)
DimZipCode (10001, 10002, 10003...)
Everything else gets Surrogate Keys.
Yes, with one exception:
A table which implements a n:m relationship between two other tables, a pure link table, does not need such a field if it has two fields only, referencing the two primary keys of the linked tables. The primary key of the link table then consists of the two fields.
As soon as the link table has extra information, it needs a simple single-field primary key.
Having said that, there may be more exceptions; database design is a very broad field...
EDIT: Added more in the previous sentence.