1) Relatively small DB application with a well-designed database, with a properly normalized structure consisting of parent/child, or, master/detail tables
2) No more than 20 tables tops with a small number of rows (at most a couple hundred rows in the largest of the 5 or 6 detail tables)
In a well designed app, to reduce redundancy and save disk space, databases are normalized, but would it make sense with a small application to simplify things, namely the model/view design -- to normalize some data? In the project I'm working on, my detail table will probably never have any more than 50 or so records and the detail table, jeez, no more than say 500...Instead of creating 2 tableviews, 2 S
QL models (one for master, one for detail), a
QSortFilterProxyModel and managing the relation, would it maybe make sense to just add a column to my detail table and eliminate the master table altogether and apply the
QSortFilterProxyModel there? That totally goes against my perfectionist nature, but given time constraints and my inexperience, wouldn't it simplify the implementation by taking me down to one view and 2 models?
Just something I'm thinking about as I'm struggling to figure out where to apply the
QSortFilterProxyModel (one example I found applies it to the master, another to the detail -- oooof)
Bookmarks