Łukasz Mróz has been working at e-point since August 2011. He began as a Java programmer and after a few months he switched to being a DB Architect. Today he shares with us his unique perspective on OneWebSQL - both as a programmer and as a DB Architect.
Can you tell us something about the project you're currently working on?
What's your role in the project?
Currently I am the Junior Systems Architect. We are working on a mobile business application for one of our clients. The app will be used as a mobile office for the client's e-commerce system, available for 30 countries. After the web evolution, there is now time for the mobile revolution. I discover user needs and then I design the user interface, databases and integration between the systems.
What database-related tools do you use in your work? The mobile application
you're talking about uses OneWebSQL mobile fork which
Rafał announced on our
blog recently, right?
Yes, we use OneWebSQL, both the standard version and the mobile fork for mobile devices. I worked with PostgreSQL, DB2, Sqlite, and OneWebSQL. ORM surprisingly is working very well not just with the web, but even with mobile applications. We anticipated possible memory or performance problems (at the moment there are 61 tables in the mobile database!), but most of the performance is contingent upon the application code and user interface interactions, rather than the database access. The databases were designed with Sybase Power Designer.
What database related tools have you used before e-point?
During my master studies at the university I used:
- MS SQL Server (Integration - ETL, Analytics and Reports included)
- Oracle 10g
- Sybase Power designer,
- IBM Rational Architect,
- Enterprise Architect trial.
- MySql database,
- Hibernate and JPA ORMs.
What are your experiences with these tools?
I obtained my Bachelor's Degree after implementing the recruitment system application for foreign students. This was a web app for the university that I implemented with a colleague. We used PostgreSQL database (25 tables), Hibernate ORM, and Spring Framework.
I must admit that changing the XML files, model classes, DAOs, and service layer was very painful. After the requirements changed, which happened several times, I spent too much time on these tasks. I couldn't focus on the core of the business logic, before the database access layer was ready. The JPA or Hibernate Annotations was a compromise, I think, but was still not flexible enough to meet our needs. I mean that some issues have to be done in the database - for example, specific generalization, inheritance or even generic table structure and ORM. I found that JPA/Annotations are often more trouble than they are helpful.
The second problem was queries. I tried to use criteria, but there were problems with joins for more than one table deep. The university system’s database is more transactional and has writes and reads at one time (deputies are processing applicants and applicants have interactions with university employees), the best idea is to keep the normal forms. The normal forms require more joins, so views can be used. However, there was a reporting functionality and this solution did not work. Eventually, I had to write queries for the reports in the app - with the HQL expressions. The model changes revealed trouble with the HQL. It does not check whether the query is correct until it goes to runtime. The HQL was not easy to read. I can even say "java code strings with parameters".equals(JDBC.drama()) especially if your application server initializes in almost two minutes.
How do these other tools compare with OneWebSQL?
I like OneWebSQL because it is more flexible with the object-oriented query structures than any other tool. After the changes in requirements, I can very quickly fix the project code because of the compiling errors and warnings. Static typing is more desirable feature here; in comparison to django ORM, it's better to see a problem in the model before the runtime. Changes in the requirements become a project driver, and because the data access layer is ready, you can easily correct model-business-logic mismatch and then implement the core focusing on business part. Consider a multi-platform agile mobile project with a 61-table data model, for example. I cannot imagine how much time would be wasted on the fixing the model and DAOs for each of the platforms without OneWebSQL.
Thank you very much, Łukasz, for talking to us today.