Does MS Access 2007 support internal foreign keys within the same table?
Yes. Create the table with the hierarchy.
id - autonumber - primary key
parent_id - number
value
Go to the relationships screen. Add the hierarchy table twice. Connect the id and the parent_id fields. Enforce referential integrity.
Yes it does.
Under database tools and relationships you need to show 2 copies of the self-referencing table. It will name the second copy Table_1. Then you setup a relationship between the primary key in "table" and the foreign key column(s) in "Table_1".
Yes it does and unlike many more capable SQLs (e.g. SQL Server) you can also use CASCADE referential actions on FKs within the same table, which is nice.
Related
In SQL Server 2012, I have a User table to store application users. I also have an Organization table which has a LastModifiedBy field in which I would like to store the UserID of the last person to modify the values within the table via an ASPX page. Should I create a foreign key relationship between the LastModifiedBy field and the UserID field within the Users table?
I would also like to add a LastModifiedBy field to the Users table itself. Should/can I create a self referencing foreign key constraint on this table? If this is possible, is it a horrible idea?
Any perspectives on pros and cons of creating these foreign key constraints would be greatly appreciated.
What you are describing is what foreign keys are made for. These foreign keys are at the very core of relational databases. Even if they might give a slight performance impact when inserting new rows, because it has to check if the referenced key exists, it should not be avoided.
I have table in my data base with these specs:
one PK
3 fields with foreign key
some statistic fields
problem is here:
In every row only one FK field will be filled.
What is the best solution A or B?
A- define 3 FK for my table
B- define one field as FK_TYPE and one field as DEMAND_FK and use checking on FK_TYPE for result
Option A - if you've got to have this design, you'll need a separate column for each foreign key. There's no (standard) way to define a "conditional" foreign key.
If your system supports check constraints, include a check constraint so that exactly one of the FK columns is not null. If it doesn't support check constraints, add triggers that enforce this same check.
If I am not wrong, B can not be possible in any relational database. Foreign key can only reference to only one primary key of a table. If you use B then you have to add the constrain in application level. Otherwise use A.
In a LDM I recently made, I have an entity which has the following structure:
Building_ID (Primary Key, Foreign Key),
Plant_ID (Foreign Key),
Build_Year (Primary Key),
Size
I need to create a table in a SQL database using this design. The question I'm running into is how do I handle the primary keys here? Is it OK for a SQL table to have multiple primary keys? If the answer to this question is yes, then which column should act as the unique index? Should I create a new column to act as the unique index identifier?
Any SQL table for any relational database system (SQL Server, Oracle, Firebird, IBM DB2, Sybase etc.) I know can only ever have one primary key - after all, it's the primary key - there can only ever be one.
However, a primary key can be made up from multiple columns (called a "compound primary key"). There are downsides such as: all foreign key constraints from other tables also must specify all columns in the compound PK, thus making joining the tables a bit of a pain (since you need to specify all equality constraints for all columns included in the key in your JOIN).
Besides a primary key, you can also have multiple alternate keys - other column(s) that could also identify the row uniquely. Those make excellent candidates for e.g. indices, if those can help you speed up access to the table (but don't over-index your tables! Less is more)
I am working on a database whose tables won't have any foreign key constraints except composite primary keys for some of the tables. Is it possible to map the database using LINQ to SQL and then set the foreign key constraints in the DataContext being generated?
Thanks
Yes it is possible.
If they don't exist you just have to create them manually in the designer - use the Inheritance tool from the designer view and drag from the primary key on one table to the foreign key on the other.
Important notes:
1) both tables must have a primary key defined: see my blog entry on this point
2) the datatypes of the two columns must match - an integer cannot join to a date
I am trying to model a tree relationship in a table. For instance, there are "Categories" and categories can themselves be inside a Parent category.
My schema is:
id int PRIMARY KEY,
parent_id int,
name
My question is, should I label the parent_id column as a Foreign key? Foreign implies "outside" and not self-referencing. Is there a different type of key for this purpose?
My question is similar to:
Self-referencing constraint in MS SQL, but I'm asking a different question, cascading not being an issue.
Self-referencing foreign keys happen all the time. E.g. an employee might have another "employee" as his manager, so the manager_id will be a foreign key to the employee_id field in the same table.
Foreign keys are the natural candidate for representing the parent node in hierarchical data, although they're not exclusively used for that :)
If you have very deep levels of nesting it may not be easy to performantly select out all descendants of a particular node, since most DB's do not handle recursion very well. Another approach is to use what's called the "Nested Set Model" to represent the relationships. A great article is available here:
http://www.intelligententerprise.com/001020/celko.jhtml
A foreign key between two columns in the same table is often used when mapping tree structures to relational databases. However, it is not the only approach avaiable.
See this article for alternative reperesentations: Storing Hierarchical Data in a Database
I don't believe there is another type of key... a foreign key would be fine in this scenario.. it would enforce the constraint against the parent_id to ensure it references a valid id