SQL Convienience model or custom abstract model?

I am developing a piece of software which is designed to track customer complaints, and looking at QT as an option for a framework. It uses SQL as a database backend.

Background: The product is designed to track complaints for products. There is a table for a list of products, an another for batches, which has a foreign key to products (ie, one batch relates to one product).

I have been able to use QSqlRelationalTableModel for some functionality (ie, adding users which have foreign keys to department tables, sites and adding products) and this seems to work well for these simpler sections, where it is a table of data with foreign keys to other tables, where I only need to use one column of data for a combobox.

Now, the complaints involve multiple tables. One main table for the complaint, which has a foreign key to a batch (which then links to product by another foreign key). Note that batch isn't mandatory, in some cases it will be NULL. There is an investigation table, separate, which stores results of the investigation, and the complaint table has a foreign key to that.

I also want the option to line multiple investigations to a complaint, in which case, there will be potentially a many to many relationship between investigations and complaints, which may be required.

My question is, is QSqlRelationalTableModel up to the task? Most of the time, work will be done on one 'row' at a time, but I would like to keep the program performant. Does using QSqlRelationalTablelModel make sense if you only are seeing one row of data? If it loads the entire table, thats unnecessary, and I may be better of subclassing QAbstractTableModel or ItemModel and doing my own? (the number of complaints is most likely to be a two or three digit number). Also, the widgets do match up with the database rows, more or less.

All the examples I've seen online regarding the SQL table models, involve setting up relations with one table, but what if table A has a foreign key to table B, which has one to table C, and you need to display information from table C as well as B in the form? Can QSqlRelation do this and allow the necessary widget mapping? Also, if the data is worked on one row at a time (via a form with widgets mapped), do these models cause unnecessary overhead by loading the entire table, or can you limit it to loading select rows? Or does this not matter?

If these classes aren't up to it, I'll have to subclass the AbtractModel, but I would like to avoid that if possible.

Creating your own table model would be subclassing QAbstractTableModel, which is not really difficult.

I of course don't fully understand your requirement but I am wondering if you need to have everything in one single model?
Is there a single table view that shows everything?

Cheers,
_

I suspected this may be the case. Thank you.

One more question, many of the views will involve displaying information from different tables. In this case, the "Customer" table points to a "Batch" table for specific batch details, which then points to a "Products" table. Many of the screen will need to display all this information (ie, batch number and product name) Is it better to create a singular customers model which pulls table from all three and incorporates all the necessary data as one object (I would think SQL joins would come in handy here), or, keep each table as a separate model, and stitch the relevant UI components to the relevant model. In this case, the complaint object would contain a batch which contains a product.

I would say that a model should only have the columns necessary for the views that display it, especially if not all views are always visible simultaniously.

Depending on your database you might even be able to make a "view" at the DB side and just display that table with a standard QSql model.

Having data for more than one view accessible through the same model mostly makes sense when these views needs to be easy to synchronize, e.g. highlghting the same row.

Cheers,
_

Sorry about the repeated questions, perhaps I should get a book.

In this instance, the one view, that is, the screen will display information from all three tables (a complaint will appear, with batch and product details), so I should make the necessary columns from "Batch" and "Product" be columns in the Complaint model, and just have that one model retrieve all the necessary information, correct?

I do have one last (for now) question, which may not suit this thread.

What is the best way (or where can I find documentation to that effect), for implementing QSqlRelation like mapping for Abstract models? That is, I wish for the Batch, to have a combobox listing all available batches the user can choose from. With the convienience classes this is easy, but I'm assuming that the abstract table model has no such support, and I must do this myself?