Let's say I have two tables:
Items
Property1 (relates to PropertyName)
Property2 (relates to PropertyName)
Properties
PropertyName (index, single key alternate)
When making a normal relation in Dynamics AX 2012, I get the following Best Practice error: Only foreign key constraints are allowed on this table.
I can create a single key alternate foreign key relation to fix the best practice error. However, I can only do this for one of the fields. If I do it for both, I receive a compilation error about duplicate alternate keys.
Is there some way to create normal relations like we used to in AX 2009 without a best practice error?
or.. How can I do two foreign key relations on two fields that relate back to the same column?
Thanks
When setting the properties on the relations, set UseDefaultRoleNames to No, then give each relation a unique Role.
If you add a relation Field, you must add as a foreignkey-field. It also add automatically a field in your table. Then the BP Error must be solved.
Related
I am new in laravel. In my tutorial video teacher use foreign in migration but,i can create my relationships without it and use just belongTo and hasMany.When i use foreign can not delete one post easily (error is you can not delete because parent foreign has child ......).
my question is my way is good or not? and why?
Thank you all
Your way is good but I think foreign keys are better. Had you not had that foreign key, you would have deleted the post but all that post's children (referred to as orphans because they no longer have a parent) would have stuck around. In order to get around the foreign key error, you would need to first delete all the children for that post, and then delete the post.
The good news is foreign keys can also do this for you so you don't need to worry about keeping track of all the children. When you setup the foreign key, if you add the on delete cascade clause, when deleting the post, the database would automatically remove all of the posts's children for you and deleting a post without first deleting the children would no longer result in an error.
If it's your preference to keep the children around even when the post is deleted, you can use on delete set null instead which would simply set the children's foreign key to null rather than delete the record.
This is all useful for enforcing data integrity (databases should contain only accurate and valid data).
The answer really is not 'is this good practice in Laravel' so much as 'is this good practice for database management'.
There are many articles on the topic as to the good and bad side of using foreign keys. Here is a good explanation on the DBA stack exchange
https://dba.stackexchange.com/questions/168590/not-using-foreign-key-constraints-in-real-practice-is-it-ok
My personal preference is to use them to maintain data integrity. The real power comes in adding cascading deletes to the relationship (if applicable to your design).
It really comes down to how good you want your database to be.The main reasons to use foreign keys in your database are
To prevent actions that would destroy links between your tables
This would prevent the invalid data from being inserted to the foreign key column as it has to point to a existing value
Also defining foreign keys makes your query faster depending on database I don't know the exact milliseconds but if I find it out I will post it.
Well from the laravel point of view the way you do is a better way as this is how one of the main teacher of the Laravel(Jeffrey Way) teaches in the getting started with laravel series.
Foreign Keys are the way to define relationship between tables in your database whereas Laravel belongsTo() or hasMany() is a way to define relationship between tables in Laravel
What is the difference between defining a foreign key VS just creating an integer column named user_id?
// create_posts migrations
$table->integer('user_id')->unsigned();
// vs
$table->foreign('user_id')->references('id')->on('users');
Can they be used interchangeably? What purpose do each one serve? Which is considered a best practice, first or second definition?
Edit
The command $post->user() will work either ways, so what advantages does usage of a foreign key bring?
$table->integer('user_id')->unsigned();
// Above command is creating a column in database and it is required to have the required table structure
$table->foreign('user_id')->references('id')->on('users');
// Above command is creating foreign key index and making reference to id in users table.
As you can see from command explanations they can't be interchangeable, you need first command to have second command without first second command would complain.
Best practise is to use both of them together.
Few of advantages are listed below:
You can implement cascade update/delete.
Database level validation that only valid values of user_id is recorded ( to avoid some one entering 999999 which might be invalid or non existing user_id).
Above two are main advantages and you can express multiple scenarios how above two can be life saviour.
Let's say in post table by human error or bug in script makers user_id = 9999. What you think $post->user() will do?
Unless you can have a post without any reference to user you can see there could be multiple logical issue you may find if foreign keys are not used.
Think of foreign keys as enforcing relations and taking care of post if user is removed / deleted from db.
No, They can't be used interchangeably and each one has its usage. Use index when you want to define index on column, means database index, see here. But when you define a foreign key it set a index to that column (for searching, ...) and also make a relation between user_id and id column in user table, so if there is a user by id 10, then you can use user_id = 10 on another table. Also it has another benefits such as making sure your data are integrated. For example you can't delete user by id 10 if there is article that belongs to this user. For more information see this.
The first line, will only create a user_id column not something special,
while the other line will create a column as a foreign key which will be tightly coupled with id column of users table, this will create some limitations.
read about foreign key reference
For the best practices I always use:
$table->unsignedInteger('user_id');
$table->foreign('user_id')->references('id')->on('users');
Don't mix the definition of index with foreign key, they don't mean the same.
How can I define column to be unique when creating logical model? It's because I want to create relationship 1:N and both columns are not primary key. I tried to define surrogate keys when defining relationship and typed column names in field Name of source/target, but when creating relational model, I don't get what I want.
So basically I want define which columns from tables go into relationship and define unique constraint over column with multiplicity 1.
I found that I can set up Unique Constraints in the Relational Model in the Table Properties. There is an item in the list called "Unique Constraints" name the Constraint and then add the column. After that click the check box to generate the DDL for the constraint.
just use the UNIQUE constraint.
http://docs.oracle.com/cd/B19306_01/server.102/b14200/clauses002.htm
BTW, why are you using a FK that does not reference the PK? You might need to do this, but you might also consider refining your conceptual model so that the reference can refer to the PK.
Is it possible to set null/blank lookup values on relationships in CRM 2011 when they open from the parental/referrential entity?
Example, if you create a new 1:N relationship between the entities opportunity and account holding an agency value. When creating a new opportunity from an account, this account is prefilled in both the potential customer lookup field and the agency lookup field.
This can easily be remedied with a javscript, clearing the field onload, but can this be done earlier, in the attribute mapping, or is it always a post-fix to correct the default action?
I had the same issue in Crm 4. So I suppose it still exists in 2011.
You cannot remove the relationship mapping of the primary attribute, though I've never understood why this automatically maps to fields of different relationships.
In this case you are just best off using JavaScript to perform the following logic:
If the form is in create mode and both fields contain the same value then clear the duplicated field.
This logic should ensure that it only clears the fields in this circumstance.
This is not possible without Javascript.
MS CRM doesn't give you an option to counter the autofill of the mapped field. It will always be automatically filled in by the system.
I can see that Extended Data Types can have Array Element which seems to make it a composite type. I'll be looking into that later.
What are the relations used for? MSDN was woefully crap at explainined what it would actually be used for. Why would you want to relate a type to a specific table and why would other tables using the type care?
When I create a new 'PersonTable' table I could have a key field called personId, creating/using a new Extended Data Types called personId and adding the relation you've mentioned. Now when I add our EDT to other tables we do not have to specify either labels or relations to our PersonTable as this it's defined by the extended data type.
In a related form (e.g. PersonSkillsTable) where our personid field has been added to an existing table it will now automatically create the dropdown/grid to select a value from our persontable. We didn't need to add our persontable to the form's Data Source.
Automatic relations between tables
Automatic lookups
Automatic "Go To Main Table" menu option after right-click