I am currently using PopSQL for my school project. Can someone help me with this problem?
The error message is self-explanatory. You need an index on the column that the foreign key refers to.
So, do create it:
create index idx_section_sectno on section(sectno):
Also, you might want to read the MySQL documentation for foreign key constraints:
MySQL requires indexes on foreign keys and referenced keys so that foreign key checks can be fast and not require a table scan.
Other conditions apply to forein keys that you want to be aware of.
Related
I recently created a relational database model and it has a lot of primary key and foreign key relations. I want to use clickhouse for my database but it turns out that clickhouse does not support foreign key and unique primary keys. Can someone tell me if I am missing anything here.
You are right. CH does not have unique & foreign constraints.
Moreover JOINs are not the best part of ClickHouse.
ClickHouse suggests to create single wide denormalized table and avoid joins as possible.
Is there any difference between
$table->integer('user_id')->unsigned()->index();
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
and
$table->integer('user_id')->unsigned();
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
For me it's the same because foreign key is an index, am I right ?
Reference to this question, it's good to index a foreign key, but database won't index it automatically.
So 2 code blocks above are different.
I think you can try to open your database schema and check for it.
I found my answer:
Some databases by default put indexes on all created foreign keys automatically.
Eloquent only does a - create foreign key - command for and MySQL automatically adds the index.
Thanks to Mittensoff from laracasts for the answer ;)
When export sql scripts by SQL Developer there are multiple options available, but either way there have to generate a UNIQUE INDEX on primary key like this
CREATE UNIQUE INDEX "SYS_C0018099" ON "TRANSACTION" ("ID")
and add PRIMARY KEY to the same table and same column
ALTER TABLE "TRANSACTION" ADD PRIMARY KEY ("ID")
So the question is: does it looks like kind of redundancy? I thought creating a primary key on a column should by default create an unique index on that column too? So why the first command is necessary?
And this may cause data redundancy?
I am on Oracle 11g so please share any ideas about why it should look like above.
Thanks in advance.
There is no redundancy - or only a little bit :)
The second command will use the index available if exists. Otherwise(if first DDL does not exists) will create an index.
The split into two commands is useful when you had given a proper name to the index and want to keep it.
UPDATE: The link indicated by Thomas Haratyk is a must read, I really like it: http://viralpatel.net/blogs/understanding-primary-keypk-constraint-in-oracle/
UPDATE2: a_horse_with_no_name is right, it can be done in a single statement like:
alter table TRANSACTION
add CONSTRAINT pk_test PRIMARY KEY (id);
So, it will keep the name(won't create a sysblalbla object name) and if you use the 'USING INDEX' keyword you can specify index atributes, for example storage atributes.
But again, you will not have any problems with those two statements, only an index is created.
Probably SQL Developer prefer to get a ddl per object and there might be cases when it's better its way.
I have a table, let's call it Users. This table has primary key called Id. Despite having Id as primary key (unique clustered), it has other index (unique nonclustered) on the same column(Id).
I would like to drop this constraint, but foreign keys reference this unique nonclustered index and I get The constraint ... is being referenced by table... error.
What is the best way to drop such index? Do you have any scripts that drop, do something, and recreate foreign key on specific column in specific table? There is a lot of foreign keys, so it would be nice if I could do it automatically. I could use INFORMATION_SCHEMA and other system object to extract information about these keys, but I don't want to write, what have already been written or can be done in other way.
In order to drop a nonclustered index that is referenced by a foreign key you must furst drop the foreign key constraint.
Take a look at the following scrips available from a poster over at SQL Server Central. They may require some tweaking for your "exact" requirements however they provide the basis for scripting out and then subsequently rebuilding foreign keys.
Scrip out Foreign Keys
The two-index approach can make sense:
The second index is probably much smaller than the clustered index, and would more easily fit into memory
The second index might include a selection of columns that benefit specific queries
For dropping the second index, you'll have to drop all foreign keys that refer to it first. Here is a link to the script I use to drop & recreate foreign keys.
For instance, suppose I have table A. Then I have tables B-Z that have a foreign key to table A's primary key. Then perhaps there are also some tables that have a foreign key constraint to a table in B-Z's primary key constraint. Is there any easy way to clear out table A and all of the tables that refer to A (or that refer to a table that refers to A) without having to explicitly delete from each table or add an ON CASCADE constraint to each foreign key?
Note that this is mainly for testing purposes, not to be used in production. I would just drop the entire schema and start over again, but that simply isn't feasible for every test (considering how long it takes to build the schema).
I think the most efficient way to do this would be to drop all the FK's, truncate the tables, and then rebuild the FK's.