Yes, I did mean to reference the project_id rather than the user_id FK relationship in the previous post:
tbl_project_user_role ADD CONSTRAINT
FK_project_id FOREIGN KEY (
id) ON DELETE CASCADE ON UPDATE CASCADE;[/sql]
With this in place, if you delete a row in the "parent" table, i.e. tbl_project, and there are any associated rows (i.e. via the FK project_id) in the tbl_project_user_role table, these will be deleted as well. However, there is no FK defined on tbl_project back to tbl_project_user_role, so simply deleting a row in this table will not delete rows in your tbl_project table.
Of course, you can also take care of this programmatically if you prefer and not define it this way in MySQL. Then, of course, you would need to alter how you delete projects by first manually deleting from any other table that have FKs tied back to the tbl_project.id field.
You are correct that the foreign key is not specified this way in the DDL statement for creating the table. The book is attempting to say database independent, and the low level DDL statements for tables are intended to be general (i.e. not MySQL specific).
If you download the actual code for the application, there are MySQL specific SQL (DDL) statements for all objects in the database and these are defined this way there.
You can get the code chapter_by_chapter from the packt site:
or grab it from github: