ORM
| Platform/Technology | Pros/Cons |
| Django | Pros: – Speed + scalability: build and scale projects quickly, just about everything is included “out-of-the-box” – Internal/external consistency, software reuse – Versatility: templates allow for modifications to be made within the application to, say, printouts without having to modify code – Third-party support: allows for mssql-django third-party backend to make Django compatible with Microsoft SQL Server, and has plenty of other support/guidance/documentation thanks to its widespread use Cons: – Features not as accommodating for smaller projects – Lack of flexibility: mainly one way of doing things with Django Source Source |
| SQLAlchemy | Pros: – Performs well with complex queries – Flexibility/portability: can easily switch between different database engines, and supports a relatively large number of them – Built-in support for Microsoft SQL Server Cons: – Complex, steep learning curve – Much smaller community than Django, and as a result, less third-party support Source |
| Hibernate | Pros: – Reliable/stable, scalable – Also has a large community and third-party support – Benefits of object oriented model: can use polymorphism and inheritance with SQL Cons: – Would have to switch language to Java from Python – Performance issues when queries are complex – Downsides of object oriented model: possible performance problems stemming from OOP and SQL conversion Source |
Database
| Platform/Technology | Pros/Cons |
| SQL Server 2019 | Pros: – Large performance improvement over SQL server 2008. – Improved security features which are necessary for client. Cons: – Expensive at small scales for licensing and operation. – Can be complex to configure for small organizations that do not have dedicated personal for it. resources: 1. https://www.microsoft.com/en-us/sql-server/sql-server-2019 |
| MongoDB | Pros: – NoSQL database – Supports fast development and iteration. – Supports many data types and programming language compared to SQL server Cons: – Less feature rich for joins and relational databases. – consistency resources: 1. https://www.mongodb.com/ |
| Oracle Database | Pros: – Scalable – feature rich for larger and more complex databases Cons: – Security – high cost of running – Again, complex to maintain without dedicated admins. resources: https://www.oracle.com/database/ |
Frontend/Interface
| Platform/Technology | Pros/Cons |
| PyQt | Pros: – Good documentation – User-friendly – Lots of UI components Cons: – Large learning curve – Costly |
| Kivy | Pros: – Supports many platforms – Can access the code across different devices – Easy to use widgets Cons: – Large package size – Small community – UI isn’t typical |
| Tkinter | Pros: – Don’t need to install anything – Lots of widgets provided – Simple syntax Cons: – Difficult to debug – GUI is not as pretty as others |
Top 10 Python GUI Frameworks for Developers – GeeksforGeeks
Backend
| Platform/Technology | Pros/Cons |
| Python (language) | Pros: – Easy to type and understand – Support for functional programming and OOP – Allows for easy use of Django and PyQt – Many additional supporting libraries along with Django – Source Cons: – Some design restrictions – Not as fast as other languages like Java, C, and C++ – Not great for manipulating memory |
| Java (language) | Pros: – Multithreading helps maximize CPU utilization – Entirely OOP-based, allowing for extensive libraries – Automatic memory allocation and garbage collection – Very widely used, especially in conjunction with SQL – Source Cons: – Multithreading can result in deadlocks – Tends to use more memory than other languages – Can be very slow at times |
| C# (language) | Pros: – Easy-to-use OOP design – Versatile and compatible across platforms – Runs faster than the others listed – Great support with .NET – Source Cons: – Somewhat limited to only Windows – Slight learning curve as opposed to scripting languages – Its virtual machine may cost some additional runtime – Source |
| Ghostscript (PDF interpreter) | Pros: – Can run on all operating systems (Windows, macOS, Linux) – Under development for over 30 years – Easy to use and works well with the current system – Source Cons: – Not very well known or widely used – Documentation is a bit difficult to navigate |
| Scribus (PDF interpreter) | Pros: – Versatile and has lots of different uses – Usable on all operating systems (Windows, macOS, Linux) – Has a wiki for users to make posts and how-to guides Cons: – Downloading is not very user-friendly – Wiki seems inactive apart from official documentation |
Our Choices
- Choice 1 – ORM
- For the database abstraction layer, the team decided to keep the current Django ORM implementation, which also uses the mssql-django third-party extension to make it compatible with the Microsoft SQL Server database. We chose to stick with Django not only because it already has a base implementation in the project and will integrate well with the existing Python code, but also because of its benefits, like speed, scalability, versatility for users in the future, and the third-party support with mssql-django that make it especially beneficial for our goals in this project and achieving these in a timely manner. Django also is quite popular and has widespread use, which means the team has access to a large amount of support and resources as we work. Additionally, its drawbacks would not be as detrimental as the drawbacks of switching to an alternative; for example, SQLAlchemy’s steep learning curve and small community support could slow progress down considerably, and using Hibernate would require us to change the backend entirely from Python to Java, and this change could even lead to performance issues in the future. Note that the use of a thick client was a constraint of the existing system, and it lends itself to using an ORM to translate between the Microsoft SQL Server database and the existing application code.
- Choice 2 – SQL server 2019
- For the database we chose SQL server 2019 because the client is currently running SQL server 2008 and the department has requested they updated for security reasons. The DB has not been upgraded since its creation and upgrading directly to 2019 includes all the security that the IT admins require for the server. Thus, we decided to stick with SQL sever (2019) because it is the most familiar and hopefully will cause less friction for us, IT, and the department.
- SQL server 2019 has all the features necessary for this database, which is relatively simple, and does not require as much support as Oracle DB.
- comparison doc: https://db-engines.com/en/system/Microsoft+SQL+Server%3BMongoDB%3BOracle
- Choice 3 – Frontend/interface
- For the frontend/interface aspect, our group is going to continue using PyQt as the framework for our user interface. PyQt was the framework used before our group started working on this project. We think that this is still the best choice for the frontend/interface of our project because of how user friendly the framework is. There are a lot of documentation and other resources that can help us improve the current interface using PyQt. The project currently has an outdated version of PyQt, but we plan to update this to the current version which will hopefully allow us to use newer features of the framework.
- Choice 4 – Backend
- Our team decided to stick with the Python programming language for this project. This is what was used in previous years, and it easily inspires and works very well with our other frameworks, Django and PyQt. Our team is also very experienced in Python; we are familiar with its OOP and functional concepts. We also enjoy its ease of use and readability.
- For our PDF interpreter, our team chose Ghostscript, because we found that it works very well with the current system. Additionally, we believe that we do not need all of the different uses that something like Scribus seems to have, since we are only using the interpreter for a couple of things. Ghostscript seemed like the right choice for our needs.