Database suggestion for my custom webportal

Vajihk Morotell5 years ago

Hi Anton,

Thanks for wonderful application.

I am creating one tracking application and using mysql database for same, I want to confirm if I will use same database for traccar server as well then will it be fine ? or is there any chances that future release will drop the things which are not related to TRACCAR ?

Is it good idea to club traccar database and my application database together ?

Anton Tananaev5 years ago

I don't really understand why you would want to do something like that, but it should work.

Tony Shelver5 years ago

Also not sure why you would want to combine traccar and your custom data objects in the same DB. Having said that, I am not a MySQL expert.

We use Postgresql for our custom DB as it has much more robust GIS support than just about any other DB apart from maybe Oracle, and tends to be a standard in the GIS community.

Before you go ahead with creating your own tracking DB, do you have specific use cases where you can't simply use the standard Traccar DB?

In our case, we have more than 1 tracking application that we have to integrate, and also need more history with regards to driver, department and vehicle changes, among other things, so we created our own DB.

If you have not started development yet, take some time to map your requirements and use cases first to Traccar as it stands, and next to the specific DB you will use. When it comes down to analysing routes, points, areas, and so on, processing inside of Postgres and PostGIS (the GIS extension) is much faster and easier than if handling in the application.

With Postgres, you have the option to create Traccar and your custom DB in the same DB, but in separate schemas, or else as completely separate databases. Accessing across schemas in the same DB is faster and easier than across DBs, but for now we have chosen to implement separate databases and then have a formal integration / loading layer, as our other tracking system implements Oracle which encourages this approach.

Vajihk Morotell5 years ago

My Idea is not to relay too much on traccar API, Suppose if I want custom notifications or position then I can have it directly from traccar database with vehicle and organization info from my custom tables which has groupid and traccarid as a foraign key constraint.

I am maintaining several custom fields in my tables so using joins I can have all the details at a time instead of getting it after calling an API.

Tony Shelver5 years ago

Again, Anton would have to give his input here.

Our experience of working with another tracking system is that the database can mutate over time. The more tightly coupled you are to that DB, the more breaking changes can be introduced. The more tightly you are coupled to that DB, the more changes you will have to make.

Again, looking at the base Traccar DB, I can see some room for additional functionality and this DB changes in some areas, so it could be possible that a new major release could introduce table changes.
Anton has a lot of experience in this area, and i suspect this is why he has provided the API, which is a best practice for any general use application.

A year or two ago, we were faced with the same choice with extending our existing tracking app to support functionality that clients were asking. for, that the app provider was not able to introduce.

My experience of integrating the two systems is that the base tracking and event data is pretty easy to mirror across. Keeping the master data (vehicles, groups/departments, devices, geofences) and their relations in sync has been a lot more challenging.
We had 2 attempts at this, first using SQL Server as the base, then based on poor GIS query times and the expense of running SQL Server, we redesigned and moved to Postgresql..
Our initial SQL Server strategy was also flawed because we were tied too tightly to the source application DB, and when they introduced a new version, our integration failed and required rework.

Our experience first time round resulted in a decoupled DB implementation that is highly integrated into Postgresql and PostGIS to make optimum use of the GIS capability there (lat/longs, geolocations, geofences, customer location / area analysis, in / out of area movements and so on).

For me, you really need to work out your business and technical requirements and constraints out first, and then pick out a strategy.

Additionally, speaking as an ex-db designer / developer, it's just cleaner to use at least a separate schema to the Traccar DB

Vajihk Morotell5 years ago

I understand what you are saying, I am keeping two separate databases for my application to prevent such kind of issues.

Thanks for your detailed efforts.