Foreign Key Mismatch

[benners]

I am trying to normalise a database to remove duplicate info. I am using SQLite Expert to design the database and test sql queries.

The database is going to store information about setup installers, such as paths, installer specific info, users to install for, type and category of installer blah, blah.

I have attached the database thus far and the tables function are as follows:-

• category - stores text describing the general usage the installer comes under, such as Browser, Compression etc.
• installer - this is the main table that has relationships with the other tables and stores info about the installer file, install order etc.
• installer_user - a link table. Stores the user or computer to install the program for or on.
• package - stores the type of installer, NSIS, Inno  Nullsoft etc.
• platform - the OS architecture the installer file is compiled for.
• postinstall - a list of activities to perform when the main install has finished.
• postinstall_user - a link table. Stores the users\computers that are allowed to run the post install actions
• user - a list of computers or usernames. I might separate into two tables, undecided yet.

Now there wil be one program that deals with the installation side and another that acts as a front end for editing the database suchs as adding new files, removing old files etc.

The idea with the editing side is to be able to delete an installer from the installer table say with the id of 1 and all other pertinent information in the other tables will also be deleted. The same goes for deleting a user. All the fields relating to that user will be removed.

I have managed to get that part working for the most part. If I delete either a user or installer, the related info in the installer_user and postinstall tables are removed but since I added the postinstall_user table to link usernames to the postinstall action, this is where I get the foreign key error. If someone can explain why, I am sure it is an obvious reason for someone who knows what they are doing 😄

Cheers

Installer - Copy.db

[TheXman]

Having worked with databases for over 30 years, and after looking over your database definitions, I see several issues with your database that should be corrected, restructured, or optimized.  I am not going to go into all of those issues since this is primarily an AutoIt forum not a SQL and/or database forum.  However, I will try to answer your specific question as to why you are getting this particular foreign key error, how you can begin to trouble shoot such issues in SQLite in the future, and one way that you can resolve this particular error.

First, to identify glaring foreign key issues, you can execute the following SQLite pragma command on the database.  When you execute the command on the DB that you attached, you will see the following error.  The pragma command will not find all foreign key errors, just the ones that the processor can detect at the time.

pragma foreign_key_check;

Result: foreign key mismatch - "postinstall_user" referencing "postinstall"

Why are you getting that error?  The following excerpt from the SQLite documentation will shed some light on the issue:

Usually, the parent key of a foreign key constraint is the primary key of the parent table. If they are not the primary key, then the parent key columns must be collectively subject to a UNIQUE constraint or have a UNIQUE index. If the parent key columns have a UNIQUE index, then that index must use the collation sequences that are specified in the CREATE TABLE statement for the parent table.
.
.
.
 If the database schema contains foreign key errors that require looking at more than one table definition to identify, then those errors are not detected when the tables are created. Instead, such errors prevent the application from preparing SQL statements that modify the content of the child or parent tables in ways that use the foreign keys. Errors reported when content is changed are "DML errors" and errors reported when the schema is changed are "DDL errors". So, in other words, misconfigured foreign key constraints that require looking at both the child and parent are DML errors. The English language error message for foreign key DML errors is usually "foreign key mismatch" but can also be "no such table" if the parent table does not exist. Foreign key DML errors are reported if:

   * The parent table does not exist, or
   * The parent key columns named in the foreign key constraint do not exist, or
   
   * The parent key columns named in the foreign key constraint are not the primary 
     key of the parent table and are not subject to a unique constraint using collating 
     sequence specified in the CREATE TABLE, or
     
   * The child table references the primary key of the parent without specifying the 
     primary key columns and the number of primary key columns in the parent do not 
     match the number of child key columns.

In this particular case, the third bullet, above, is the reason why you are having an issue.  If you refer back to the result of the pragma command, it say that there is a foreign key defined in the postinstall_user table that references the postinstall table, that has a problem.  Your postinstall_user table is defined as:

CREATE TABLE [postinstall_user] (
    [installer_id] INTEGER NOT NULL REFERENCES [installer]([id]) ON DELETE CASCADE ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
    [sequence_id] INTEGER NOT NULL REFERENCES [postinstall]([sequence_id]) ON DELETE CASCADE ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
    [user_id] INTEGER NOT NULL REFERENCES [user]([id]) ON DELETE CASCADE ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
    PRIMARY KEY (
        [installer_id],
        [sequence_id],
        [user_id]
        )
    )

As you can see, there is one foreign key in that table that references the postinstall table.  sequence_id is not the complete primary key in the postinstall table.  The primary key in that table is defined as "PRIMARY KEY([installer_id], [sequence_id]))".  Therefore to satisfy the third bullet of the documentation, if you change the definition of that foreign key to match the primary key in the postinstall table, it should fix your issue.  So the definition of that postinstall_user table should look something like:

CREATE TABLE postinstall_user (
    installer_id INTEGER NOT NULL,
    sequence_id  INTEGER NOT NULL,
    user_id      INTEGER NOT NULL,
    PRIMARY KEY (installer_id, sequence_id, user_id),
    FOREIGN KEY (installer_id, sequence_id) REFERENCES postinstall (installer_id, sequence_id) 
        ON DELETE CASCADE ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED,
    FOREIGN KEY (user_id) REFERENCES user (id) 
        ON DELETE CASCADE ON UPDATE CASCADE DEFERRABLE INITIALLY DEFERRED
);

After making that change, when I delete the installer record or a user record, the related records, as you defined them, are successfully deleted.

I hope that helps.

Installer - New.db

Edited December 30, 2020 by TheXman
Attached modified DB

[benners]

Thanks Xman it does help. I did google the error, just didn't understand the explanations. I have only done 2 simple databases before this so I am still getting to grips. @jchd has

helped me before but they aren't something I use daily so forget stuff.

Quote

I see several issues with your database that should be corrected, restructured, or optimized

I would be interested in your optimization suggestions.

I seem to keep going around in circles when trying to find best practice so just decided to stick with a certain style.

• Lower case for tables and columns and underscore to separate words.
• Table and column names in the singular.
• Keep table and column names short but descriptive (with no abbreviations)
• The primary key column will be id, as long as it's singular.
• Normalise as much as possible

Thanks for the help.

[TheXman]

8 hours ago, benners said:

I would be interested in your optimization suggestions.

As I mentioned before, I am not going to go into all of the issues that I noticed.  But since you asked, I will point out a few things.  Please keep in mind that all relational database management systems (MS SQL Server, Oracle, Postgre, MySQL, SQLite, etc.) have their own little quirks and differences.  Since you are working with SQLite, my observations and suggestions will be targeted specifically towards SQLite.

• In several of your table definitions you have an INTEGER PRIMARY KEY defined with UNIQUE.  For example:

  CREATE TABLE [category] (
      [id]    INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT UNIQUE,
      [class] TEXT NOT NULL UNIQUE
  );

  An INTEGER PRIMARY KEY, by definition, uniquely identifies any given row in a table.  So adding UNIQUE constraint to an INTEGER PRIMARY KEY definition is superfluous.

• In several of your table definitions you have an INTEGER PRIMARY KEY defined with AUTOINCREMENT (see example above).  As stated in the SQLite documentation for AUTOINCREMENT: "The AUTOINCREMENT keyword imposes extra CPU, memory, disk space, and disk I/O overhead and should be avoided if not strictly needed. It is usually not needed.".  INTEGER PRIMARY KEY and AUTOINCREMENT work similarly in that they both will maintain/generate a unique rowid for you if NULL is used for its value upon insert.  However, if you use the AUTOINCREMENT keyword, it will never reuse previously deleted key values.  It does this by creating and maintaining an additional table (sqlite_sequence) that keeps track of the highest used AUTOINCREMENT keys.  Based on the description of your project, there doesn't seem to be a need for the additional AUTOINCREMENT functionality.

• In general, I prefer to make explicit SQL table definitions as opposed to implicit ones.  In several cases, you use the UNIQUE column constraint to make sure that values are unique.  What this does, implicitly, is to create a UNIQUE INDEX on that column.  In my opinion, it is better to explicitly create any UNIQUE INDEXES yourself.  Doing so makes it easier to see and maintain these indexes as well as gives you more control over the indexes themselves.  Some SQL tools, unless explicitly told to do so, do not even show implicit SQLite tables and indexes.  Implicit indexes in SQLite begin with "sqlite_autoindex_".  If you query the sqlite_master table (select * from sqlite_master), you will see all of the implicitly created indexes.  Of course whether use the UNIQUE column constraint or explicitly define your unique indexes is a personal preference.  But my experience has taught me, for several reasons, that it is usually better to define them explicitly.

Those are just a few of the things that stuck out the most. 

For being just your 3rd database definition, I think you did a pretty good job of normalizing it and getting the foreign key relationships relatively correct.  Kudos!

Installer - Original.db.sql

Edited December 30, 2020 by TheXman

[jchd]

200% agreed!

[benners]

Thanks for the extra info. I'll make the changes to the db 😀