I have 2 tables:
group_config (id_group_config, owner_id, name_group_config)
group (id_group, id_group_config, name_group) - id_group_config is FK to group_config
So basically, a user (owner_id) creates a group_config, then creates a group which references this group_config. Pretty standard, but I want a constraint that the name_group must be unique per owner_id.
Only way I found to do this would be to replicate the owner_id on the group table too, which could cause inconsistencies.
Am I missing something?
thanks
Since a group_config can't exist without owner_id You should make the PK of group_config a composite PK consisting of owner_id and group_config_id. You need to be careful about referential integrity constraints here e.g. what happens when you delete an owner?
This will automatically make the FK in group be that composite key.
To make the name_group unique per owner in group table, you create a unique index composed of the columns owner_id and the name_group.
Related
I have a table A that has n number of columns: amongst them id (primary key), name and org_id. Names must be unique within org_id, so I am slapping unique key constraint on that pair.
Now, in the application code, I have checks, where I verify if name for my entity is unique across organization.
The query looks like:
SELECT * FROM A WHERE name=? and org_id=?
I have org_id as a foreign key to Organizations table.
In order to speed up queries as I mentioned above, should I introduce an index against the name column? Or, maybe, there is no need, and the Unique Key index (org_id-name) will kick in and make my queries fast?
The UNIQUE constraint is already backed by an index. I assume it takes the form:
constraint uq_1 unique (org_id, name)
Your query should be fast already when using "equality searches", like the one you show, using the predicate:
WHERE name = ? and org_id = ?
So I have 3 tables:
Table: Albums
Columns: Id, Name, Description, Author, Folderpath, Thumbnail, Upvotes, Downvotes
Table: AlbumsConnection
Columns: Id, AlbumId, AlbumImagesId
Table: AlbumImages
Columns: Id, InAlbum, Imagepath
So far I've been using these tables without actually using foreign keys. Am I supposed to use foreign keys here? I understand that I'd have to add 2 foreign keys to AlbumsConnection, 1 for each table and each foreign key will reference to the primary keys ( which are the ids ) of the other 2 tables. Is that correct?
Foreign keys help ensure relational integrity of the database. There is no requirement for declaring them explicitly, but it is a good idea, particularly if you are learning to use databases.
The foreign key let's the database know that a column in one table is related to a column in another table. I don't think MySQL's optimizer uses this information explicitly, although it does create an index on the foreign key column (unlike most other databases).
In addition, a declared foreign key relationship can help you deal with changes to the database. It will prevent invalid albums from being inserted into the junction table. If you delete an album, it gives you control over how the deletion and updating is handled (via cascading constraints).
I just starting to use Foreign Keys to enforce the contents of certain Columns and want to be sure I'm putting the Key on the correct table.
In a situation with 2 tables that have a one to many relationship.
e.g.: customers (one) and orders (many).
Where I want to ensure a valid customer number is used in an orders column.
I'm I correct in saying the Foreign Key would placed on the orders table.
e.g.: orders (columnX) references customers (columnX)
Remember that a foreign key is a referential constraint that says the range of values in a table column(s) is being scoped by another table. Specifically, for your example, you would have a customer_id column in your order table that would be a foreign key back to the customer table, meaning that the in all cases you need a valid customer id in order to insert a record in the order table.
Yes, the primary key (typically a customer id) on the one table (customers) should be linked as a foreign key on the many table (orders) in a one-to-many relationship. Each order can belong to only one customer, but a customer can place many orders.
Foreign key should necessarily be a candidate key for a table (say table1)? I know that Foreign key references primary key of some other table (say table2). But for the table1, is it necessary that it should be candidate key?
By definition a foreign key is required to reference a candidate key in the target table (table2 in your question). A foreign key does not have to be a candidate key in the referencing table or be part of a candidate key in that table.
No. You can have a 1:N relationship, the FK requirement just says that the field has to exist in the other table. Whether that field is unique or not, does not matter.
For reference:
a candidate key is an alternative to a PK, it can be one field or the combination of fields (as in a concatenated key)
all this establishes is that there is more than one way to uniquely identify a record of the table
a good alternative to an employee_id might be ssn (social security number)
a concatenated key is multiple fields that make up the uniqueness of a record, which can either be an alternative to a PK, or together, act as the PK
because RDBMSs follow at least 1NF, all the fields of the table could be used as the concatentated key
Note: this is a bad choice and only serves as an example
think of an employee_id field as the one PK of the table, but the combination of firstname,lastname, and startdate would probably uniquely identify everyone on your employees table
Note: this is an example, there would probably be better alternatives to this in practice
Does a Join table (association table) have a primary key ? many to many relationship. I've seen some Join tables with a primary key and some without can someone please explain when you would have a primary key in a join table and why?
Thank you in advance;-)
In a pure 'join' or junction table all the fields will be part of the primary key. For example let's consider the following tables:
CREATE TABLE USERS
(ID_USER NUMBER PRIMARY KEY,
FIRST_NAME VARCHAR2(32),
LAST_NAME VARCHAR2(32));
CREATE TABLE ATTRIBUTES
(ID_ATTRIBUTE NUMBER PRIMARY KEY,
ATTRIBUTE_NAME VARCHAR2(64));
A junction table between these to allow many users to have many attributes would be
CREATE TABLE USER_ATTRIBUTES
(ID_USER NUMBER REFERENCES USERS(ID_USER),
ID_ATTRIBUTE NUMBER REFERENCES ATTRIBUTES(ID_ATTRIBUTE),
PRIMARY KEY(ID_USER, ID_ATTRIBUTE));
Sometimes you'll find the need to add a non-primary column to a junction table but I find this is relatively rare.
Share and enjoy.
All tables should have a primary key. :-)
You can either use a compound foreign key, or a blind integer key.
You would use the compound foreign key when there are no other elements in your association table.
You could use the blind integer key when the association table has elements of its own. The compound foreign key would be defined with two additional indexes.
It depends on the records you are associating. You can create a composite primary key on the id's of the associated records as long as you don't need multiple records per association.
However, its far more important that you make sure both these columns are indexed and have referential integrity defined.
Relationship tables frequently have three candidate keys, one of which need not be enforced with a constraint, and the choice of which key (if any) should be 'primary' is arbitrary.
Consider this example from Joe Celko:
CREATE TABLE Couples
(boy_name INTEGER NOT NULL UNIQUE -- nested key
REFERENCES Boys (boy_name),
girl_name INTEGER NOT NULL UNIQUE -- nested key,
REFERENCES Girls(girl_name),
PRIMARY KEY(boy_name, girl_name)); -- compound key
The "Couples" table lets you insert
these rows from the original set:
('Joe Celko', 'Brooke Shields')
('Alec Baldwin', 'Kim Bassinger')
Think about this table for a minute.
The PRIMARY KEY is now redundant. If
each boy appears only once in the
table and each girl appears only once
in the table, then each (boy_name,
girl_name) pair can appear only once.
From a theoretical viewpoint, I could
drop the compound key and make either
boy_name or girl_name the new primary
key, or I could just leave them as
candidate keys.
SQL products and theory do not always
match. Many products make the
assumption that the PRIMARY KEY is in
some way special in the data model and
will be the way to access the table
most of the time.
...HOWEVER I suspect you question is implying something more like, "Assuming I'm the kind of person who shuns natural keys in favour of artificial identifiers, should I add an artificial identifier to a table that is composed entirely of artificial identifiers referenced from other tables?"