Android app: Database

Aan het begin van de maand decmeber heb ik een simpele ERD (Entity Relationship Diagram) opgemaakt om de data te visualiseren die mijn app zal nodig hebben en de relaties hiertussen. Hierna ben ik begonnen aan een flow schets van mijn app. Dit heb ik gedaan zodat ik een overzicht had van de vooruitgang en om een ruw idee te krijgen van de werking van de app.

Voor de communicatie tussen de database en de app had ik een aantal opties.

SQL:

• De bekende en veel gebruikte SQL type database. Met deze soort database heb ik al ruim ervaring. Het vergt veel tijd om op te bouwen maar eenmaal dat deze opgebouwd en ingesteld is is het een krachtige tool.
• De reden van deze lange opstel tijd is omdat SQL databases een initieel database schema nodig hebben waar de data zich aan zal moeten houden om de werking te garanderen, terwijl bij NoSQL databases dit een dynamisch schema is voor ongestructureerde databases.
• SQL databases hebben ook een erg krachtige query taal, namelijk SQL(structured query language) dat zich baseert op het manipuleren van data in geïndexeerde tabellen, dit zorgt er voor dat het relatief makkelijk is om erg complexe verzoeken te doen aan de database, terwijl dit bij NoSQL databases gebeurd met een UnSQL (unstructured query language) dat zich baseert op het manipuleren van documenten wat het vaak veel moeilijker maakt om complexe verzoeken te schrijven en kan verschillen in syntax van applicatie tot applicatie.

Non-SQL:

• Met NON-SQL databases had ik nog nooit gewerkt, maar aangezien ik nog student ben en erg leergierig was heb ik me een beetje verdiept in dit soort Database. In mijn geval was dit Firebase Database, ik heb ontdekt dat dit erg eenvoudig op te stellen was en dat de speciale functie van dit soort database was dat deze je data live synchroon houdt over al je toestellen zolang er een internet verbinding was. Dit vond ik erg interessant en het bespaarde me bovendien ook veel tijd om een refresh functie te implementeren bij de gebruiker.
• Het verschil tegenover reguliere SQL databases is dat NoSQL (Non-relational) databases data kunnen bijhouden als een boom van key-value pairs en deze document based zijn, waarbij SQL(Relational) databases de data bijhouden in tabellen met geïndexeerde rijen als data. Dit zorgt er voor dat NoSQL databases beter zijn in hiërarchische data op te slagen.
• Door een krachtige hiërarchische structuur bij te houden maakt dit het heel makkelijk om met big data te werken wat erg nuttig kan zijn voor het verzamelen van data om de AI te verbeteren over tijd.
• Een groot voordeel van de speciale synchronisatie functie van firebase is dat ik de app op deze manier kan upgraden zonder dat de gebruiker zijn app zelf moet updaten. Dit doe ik door plant type opties toe te voegen in de firebase database voor het toevoegen van planten die dan ook ondersteunt worden door mijn AI analyse systeem.
• Verder zorgt firebase er ook automatisch voor dat er lokale persistentie is van data, dus als de gebruiker niet meer verbonden is met het internet/de database dan kan de houd de app een lokale toestand bij van de database waar deze dan mee werkt. Als er dan lokaal veranderingen plaatsvinden dan pas de app automatisch de online database aan zodra de gebruiker terug verbindt met het internet/de database.

Besluit:

De voordelen van een NoSQL database als Firebase zoals synchronisaties, big-data mogelijkheden, flexibiliteit van dataschema, korte opsteltijd en snelle aanpasbaarheid hebben me ertoe overtuigd om deze technologie te gebruiken. Ook is dit al makkelijk te implementeren in Android en zal ik in mijn specifiek geval geen last hebben van de moeilijkheid van erg complexe data verzoeken op te stellen aangezien deze voor mijn toepassing niet nodig zullen zijn dankzij mijn eenvoudige datastructuur. Ook was een hoofddoelstelling van mijn final work om nieuwe technologiën te integreren in bestaande systemen waar Firebase een goed voorbeeld voor is aangezien het speciale nieuwe mogelijkheden bied en een opkomend platform is.