04-03 DBMS and Business Layer

When taking into consideration what the requirements for this project are, one big point that becomes immediately relevant for my work is the system architecture. I find this topic of great importance in order for a project to work out well, especially in a big one like this. The architectural decisions I make now are going to significantly influence my future work on this project. Making the right choices now can ensure the sustainability and long-term success of this project.

Problem

I think the biggest problem is currently the fact that I do not know what the unknowns of the project are. Generally speaking, I can only anticipate which questions will be the hardest to answer. For example right now, I think that turning the signal strength data into a distance is going to be the hardest part. In time I might find out though that something else is way more challenging. In any case, I will be finding answers to those questions some other day. Right now, the biggest issue at hand is to find out which technologies will allow me to rapidly adapt to the tasks at hand and allow make the many unknowns of this project known.

Possible Solutions

DBMS

I have compiled a list of database management systems in /documentation/04-03-data-layer. I think the conclusion of that research session has been, that regardless of what I choose, it should be very easy to switch to a different dbms without rewriting a single line of code. It is important that I keep my options open for the rest of my work, so compatibility with many different languages is paramount. MySQL and Postgres really shine in this category. They have been around for such a long time, that they seem to be compatible with most programming languages. This gives me the ability to use the dbms interchangeably with the programming language that I am now basically free to choose. When comparing the two with eachother, there are two notable discerning qualitites that I really care about. The first one is performance. I would very much like the program that I make to be quick and scalable, regardless of whether it is on the grading criteria in the contract or not. It seems that MySQL has an edge speedwise in read-intensive programs. The second consideration is ease of use. Here MySQL also wins out, since it does not implement as many advanced features as Postgres (MVCC, functions, object relations etc.). For these reasons I will use MySQL for the time being. If I notice that PostgreSQL's strong suits would shine (many write operations, concurrency is necessary, ...), then I can always switch.

I am not going to use NoSQL dbms because I simply wont be storing unstructured data. It should be fairly easy to normalize all of the values that I get from the BLE clients and fit them in a db schema. Stuff like MongoDB seems to have different use cases, such as storing photos, email messages or presentations.

Business Layer

Here I am pretty confident with my choice of using PHP. I have been using PHP for the last year or two, so I kind of know how the basics work by now. Server I/O and CRUD operations on the MySQL database should be easy to manage. Golang is a language I have been thinking about trying out here, since it is so fast. Furthermore, one of my main personal goals of this project is to learn new things. But since I really think that I can create more robust code with PHP, it probably is a safer bet than adding yet another unknown to the project. If performance is an issue, I can use Golang as a performance booster in processing signal data. I can still manage CRUD Operations with the PHP REST API and then somehow figure out how to use a separate Go REST API for processing the data and returning it back to PHP.

Further actions

I will proceed by first setting up a database schema and then implementing it with simple CRUD operations in Lumen. I will also see about setting up Gitlab CI so that the dev builds will automatically deploy the the server downstairs. That should hopefully speed up the dev process a bit.