QSql classes architecture
-
You should take a look a QDataWidgetMapper
That will simplify your code.
-
You should take a look a QDataWidgetMapper
That will simplify your code.
@SGaist Wow ! that indeed will simplify my code ! From the first look, i can replace my set/get methods with these models right ?
-
Yes, the Book Demonstration Example shows you how to use it.
-
Yes, the Book Demonstration Example shows you how to use it.
@SGaist Thank you very much.
-
Do you think it will be a bad practice to use different class for each table ?
Since each table has different columns and thus different queries. -
How do you want to handle queries which affects more than one table with such approach?
I would not use one class for each table, because then your design is affected by the number of tables in the database.
What if you later add one table and remove two? You would need to write one new class and remove 2.
I would use one class and implement methods to do specific tasks. This way in your code which uses this class you do not have to know how the data is stored (in which tables). -
How do you want to handle queries which affects more than one table with such approach?
I would not use one class for each table, because then your design is affected by the number of tables in the database.
What if you later add one table and remove two? You would need to write one new class and remove 2.
I would use one class and implement methods to do specific tasks. This way in your code which uses this class you do not have to know how the data is stored (in which tables).@jsulm I generaly use Inner join for queries affecting more than one table.
When it comes to Inserting and Updating, i don't want the user to be able to add new data for an instrument for example, from a form about instrument methods.In the scenario you gave, i would still have to write a couple of methods for each of the tables and delete the unused method right ? I mean each table will still need methods for the queries.
Also what about security ? I am not really sure, but isn't easier for someone to have access to an admin table data (when he shouldn't), when these data are stored in a class that he already has access in ?
-
I don't understand why you want to write something specific for each and every table?
The methods I mentioned should have generic names like: void addSomething(const Something&).
"Something" could be stored in one or even more tables, the caller does simply not care about such details.
So, the interface should not reflect your database design.It is not clear to me what you mean with security? The interface should not provide access to data which should be hidden and it does not matter how the interface is designed (whether you use one class per table or not). And who is "someone"? A developer using your interface or a real application user?
-
I currently have a method to handle each query.
So instead you suggest having something like this to be used for all the tables ?void addSomething(QString queryString){ query.exec(queryString);And for SELECT queries i should use your solution with QDataWidgetMapper and QModel ?
-
What I suggest is: decouple your interface from the database design. You can have a method for one query, you can have a method which executes several queries,... SQL database is an implementation detail and should not influence the interface too much.
The user of the interface should not care about databases and how they are designed. They just use the interface to do what ever needs to be done. Ideally it should be possible to replace your SQL database with, for example, files or a non SQL database without changing the interface, or to change the database design without changing the interface (or with minor changes).
Example: if you use QPushButton you don't care how a button is implemented on Windows, MacOS, Linux,... For you it is just a button. -
@jsulm I see ! It is clear what you suggest.
I think indeed this is a better way to proceed .
Thank you for your time ! -
You're welcome!
