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 ;)
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.
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.
I just have a quick question. Can a table have it's only primary key as a foreign key?
To clarify. When I've been creating tables I sometimes have a table with multiple keys where some of them are foreign keys. For example:
create table Pet(
Name varchar(20),
Owner char(1),
Color varchar(10),
primary key(Name, Owner),
foreign key(Owner) referecnes Person(Ssn)
);
So now I'm wondering if it's possible to do something like this:
create table WorksAs(
Worker char(1),
Work varcahr(30),
primary key(Worker),
foreign key(Worker) references Person(Ssn)
);
This would result in two tables having the exact same primary key. Is this something that should be avoided or is it an ok way to design a database? If the above is not a good standard I would simply make the Work variable a primary key as well and that would be fine, but it seems simpler to just skip if it is not needed.
Yes, it's perfectly legal to do that.
In fact, this is the basis of IS-A relations ;)
Yes. Because of the following reasons.
Making them the primary key will force uniqueness (as opposed to imply it).
The primary key will presumably be clustered (depending on the dbms) which will improve performance for some queries.
It saves the space of adding a unique constraint which in some DBMS also creates a unique index
Yes, you might do so. But you need to be careful as foreign keys can have NULL values whereas Primary can't.
Sure. You can use this approach when mapping inheritance hierarchies using the Concrete Table Inheritance or Class Table Inheritance approach, see e.g. SQL Alchemy docs
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.