I have a class that has a Primary Key as well as 2 foreign keys. Foreign combinations must be unique. I do not see a way to do this (at least since SetAttribute was deprecated).
James touched on this with SetAttribute:
How to create a Multi-Column Index or Unique Constraint with NHibernate
This might be useful to someone else, FNH mapping of unique constraint is accomplished like this:
mapping.References<FirstClass>(x => x.FirstClass).UniqueKey("unique123");
mapping.References<SecondClass>(x => x.SecondClass).UniqueKey("unique123");
Further, it is explained that this only builds the constraint in the db, but that the developer is responsible to intercept duplicate insert attempts, otherwise an SqlException will be thrown saying an UNIQUE KEY constraint was violated.
from the FNH group
Related
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 am currently learning SQL, and I have a physical data model I need to implement in code. However, during constraint creation, the numbers appearing next to FK and U started confusing me immensely. Consider the diagram. EDIT: Added the full physical model.
I know that when the matter is Primary Keys, we must have a single PK Constraint that's all the columns marked as PK. However, when the thing is FK or Unique constraints, I'm not so sure myself.
Let's assume I want to create the FK constraints for the table Opcao.
Should I create a single constraint for multiple columns, referencing their respective columns like this:
ALTER TABLE MySchema.Opcao ADD CONSTRAINT [FK_SUPERKEY] FOREIGN KEY ([prova], [aluno], [pergunta], [dataRealizacao])
REFERENCES MySchema.Integra([prova], [aluno], [pergunta], [dataRealizacao]);
Or create a constraint for each column, like this:
ALTER TABLE MySchema.Opcao ADD CONSTRAINT [FK_OPCAO_PROVA] FOREIGN KEY ([prova])
REFERENCES MySchema.Integra([prova]);
ALTER TABLE MySchema.Opcao ADD CONSTRAINT [FK_OPCAO_ALUNO] FOREIGN KEY ([aluno])
REFERENCES MySchema.Integra([aluno]);
ALTER TABLE MySchema.Opcao ADD CONSTRAINT [FK_OPCAO_PERGUNTA] FOREIGN KEY ([pergunta])
REFERENCES MySchema.Integra([pergunta]);
ALTER TABLE MySchema.Opcao ADD CONSTRAINT [FK_OPCAO_DATAREALIZACAO] FOREIGN KEY ([dataRealizacao])
REFERENCES MySchema.Integra([dataRealizacao]);
Would the Unique constraints follow the same logic? How do I know when to do one or the other?
You want to make a foreign key consisting of three columns which have to match all the three columns in the referenced table?
Then you should use in my oppinion on constraint for the three columns, because its the semantic you want to tell.
The one constraint for each column approach has the same effect, but you have to think a little to get the intension.
Some other tips: I don't get the semantic of the schema because i don't know the language the entities are named in. It would be easier if they were named in english. One thing i saw is the pergunta column which is duplicated and needs to be consistent in opcao, Integra und Pergunta table, this may lead to problems.
I generally helped me to always make an artifical auto increment primary key for every table (even the join tables for n to m relations), and always reference this artificial key. Then you have less problems (with case insensitivity for example) and the schema is in my oppinion easier to understand.
I have two tables, a Photographer and an Influences table. In the Influences table, a Photographer is able to influence another Photographer.
Relational Schema:
Here is my Diagram in SQL:
Instance Example:
My issue is when I try to delete Photographer Tom, since he influences Jason (as shown in Influences table), I get a error stating:
The DELETE statement conflicted with the REFERENCE constraint "FK_Influences_Photographer1". The conflict occurred in database "jma59", table "dbo.Influences"
If Tom was in the column EPName of the Influences table, I have no issue deleting it. I know that this is a foreign key issue but I am not sure how to handle this situation. I created two separate foreign keys that reference to the Photographer primary key. But the problem is that I cannot make it so that both foreign keys cascade on update and delete.
First foreign key is EPName and EPBDate referencing to PName and PBDate of Photographer
Second foreign key is RPName and RPBDate referning to PName and PBDate of Photographer as well.
The error is:
Unable to create relationship 'FK_Influences_Photographer1'. Introducing FOREIGN KEY constraint 'FK_Influences_Photographer1' on table 'Influences' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Any advice is greatly appreciated!
You could consider using a Trigger rather than a cascading delete to enforce referential integrity: https://support.microsoft.com/en-gb/help/321843/error-message-1785-occurs-when-you-create-a-foreign-key-constraint-tha
I answered that tables had only one primary key but could have many unique constraints.
But what else?
Primary column can never be null, a unique column can be.
Some differences I could think of:
Primary Key can't be null whereas unique will allow one null value.
You can have multiple unique keys on a table but only one Primary Key.
Some taken from WikiPedia - Unique key - Differences from primary key constraints:
Primary Key constraint
A Primary Key cannot allow null (a primary key cannot be defined on columns that allow nulls).
Each table cannot have more than one primary key.
On some RDBMS a primary key generates a clustered index by default.
Unique constraint
A unique constraint can be defined on columns that allow nulls.
Each table can have multiple unique keys.
On some RDBMS a unique key generates a nonclustered index by default.
It's hard to say what the interviewer might have been looking for. There are lots of options.
In standard SQL, a constraint declared primary key and a constraint declared not null unique behave the same at the logical level. For example, both of those can be the target of foreign key references. The interviewer might have wanted to know about how null fits into that. A bare unique constraint allows nulls; a primary key constraint implicitly declares each column not null in T-SQL.
Or the interviewer might have been looking to see whether you distinguished a unique constraint from an unique index. AFAIK, every dbms implements unique constraints by using a unique index. But a constraint expresses something about the database at a logical level, and a unique index expresses something about the database at the physical level.
SQL Server in particular
The interviewer might have wanted to see whether you knew that some computed columns, but not all of them, can be indexed. (That one's a long shot.)
Maybe the interviewer wanted to see if you'd say anything about clustering. A primary key constraint defaults to clustered in SQL Server, but an index defaults to nonclustered.
Maybe the interviewer wanted to see whether you'd say anything about permissions. You typically need broader permissions to add a constraint than you need to add an index.
I am analysing the database tables and design, I have noticed that there is a table with a column interviewID which is a primary key to the table, it is also a foreign key, the relation says it is a foreign key to itself, how is this even possible. primary key says each value should be unique and not null but foreign key says it has to be one of the existing values? Something wrong with the design? or is there some logic behind this?
When you create a new foreign key in SQL Server Management Studio all controls are set to crazy defaults: a self-referential foreign key on the first column of the table (usually the primary key column). I think somebody did this and just hit save.
It has no purpose whatsoever. Delete it.