Idag är det vanligt på större IT-företag att konstellationen i de agila teamen ändras i och med projektens kompetensbehov. Förutom de egna anställda, hyrs ofta konsulter in med spetskompetens inom olika områden. För att effektivisera projektplanering, kompetensutveckling och för att hitta kompetenser i andra team på företaget, behövdes ett verktyg för att hantera kompetenserna på företaget. Denna rapport bygger på ett uppdrag förmedlat av Transportstyrelsen. Transportstyrelsens IT-enhet växer och ett stort antal konsulter är ständigt på plats. Uppdraget gick ut på att ta fram en prototyp till en webbaserad plattform för att hantera de olika teamens kompetenser. Projektet resulterade i en webbapplikation med ett användargränssnitt byggt i Angular med data lagrad i en code first-baserad SQL-server. Kommunikationen mellan Angular och SQL-servern görs över ett Web-Api. / Today, it is common for large IT companies that the constellation of the agile teams changes based on the projects skills requirements. In addition to their own employees, consultants are often hired with excellence in different areas. In order to streamline project planning, skills development and finding skills in other teams in the company, a tool was required to manage the skills in the company.   This report is based on a mission conveyed by the Swedish transport Agency. The Transport Agency's IT unit is growing and a large number of consultants are constantly present. The mission was to produce a prototype of a web-based platform to handle teams various skills.   The project resulted in a web application with a user interface built in Angular with data stored in a code first-based SQL server. Communication between Angular and the SQL Server is done over a Web Api.

Databases are all around us, and ensuring their efficiency is of great importance. Database optimisation has many parts and many methods, two of these parts are database tuning and database optimisation. These can then further be split into methods such as indexing. These indexing techniques have been studied and compared between Database Management Systems (DBMSs) to see how much they can improve the execution time for queries. And many guides have been written on how to implement query optimisation and indexes. In this thesis, the question "How does indexing and query optimisation affect response time in PostgreSQL?" is posed, and was answered by investigating these previous studies and theory to find different optimisation techniques and compare them to each other. The purpose of this research was to provide more information about how optimisation techniques can be implemented and map out when what method should be used. This was partly done to provide learning material for students, but also people who are starting to learn PostgreSQL. This was done through a literature study, and an experiment performed on a database with different table sizes to see how the optimisation scales to larger systems. What was found was that there are many use cases to optimisation that mainly depend on the query performed and the type of data. From both the literature study and the experiment, the main take-away points are that indexes can vastly improve performance, but if used incorrectly can also slow it. The main use cases for indexes are for short queries and also for queries using spatio-temporal data - although spatio-temporal data should be researched more. Using the DBMS optimiser did not show any difference in execution time for queries, while correctly implemented query tuning techniques also vastly improved execution time. The main use cases for query tuning are for long queries and nested queries. Although, most systems benefit from some sort of query tuning, as it does not have to cost much in terms of memory or CPU cycles, in comparison to how indexes add additional overhead and need some memory. Implementing proper optimisation techniques could improve both costs, and help with environmental sustainability by more effectively utilising resources. / Databaser finns överallt omkring oss, och att ha effektiva databaser är mycket viktigt. Databasoptimering har många olika delar, varav två av dem är databasjustering och SQL optimering. Dessa två delar kan även delas upp i flera metoder, så som indexering. Indexeringsmetoder har studerats tidigare, och även jämförts mellan DBMS (Database Management System), för att se hur mycket ett index kan förbättra prestanda. Det har även skrivits många böcker om hur man kan implementera index och SQL optimering. I denna kandidatuppsats ställs frågan "Hur påverkar indexering och SQL optimering prestanda i PostgreSQL?". Detta besvaras genom att undersöka tidigare experiment och böcker, för att hitta olika optimeringstekniker och jämföra dem med varandra. Syftet med detta arbete var att implementera och kartlägga var och när dessa metoder kan användas, för att hjälpa studenter och folk som vill lära sig om PostgreSQL. Detta gjordes genom att utföra en litteraturstudie och ett experiment på en databas med olika tabell storlekar, för att kunna se hur dessa metoder skalas till större system. Resultatet visar att det finns många olika användingsområden för optimering, som beror på SQL-frågor och datatypen i databasen. Från både litteraturstudien och experimentet visade resultatet att indexering kan förbättra prestanda till olika grader, i vissa fall väldigt mycket. Men om de implementeras fel kan prestandan bli värre. De huvudsakliga användingsområdena för indexering är för korta SQL-frågor och för databaser som använder tid- och rum-data - dock bör tid- och rum-data undersökas mer. Att använda databassystemets optimerare visade ingen förbättring eller försämring, medan en korrekt omskrivning av en SQL fråga kunde förbättra prestandan mycket. The huvudsakliga användingsområdet för omskriving av SQL-frågor är för långa SQL-frågor och för nestlade SQL-frågor. Dock så kan många system ha nytta av att skriva om SQL-frågor för prestanda, eftersom att det kan kosta väldigt lite när det kommer till minne och CPU. Till skillnad från indexering som behöver mer minne och skapar så-kallad överhead". Att implementera optimeringstekniker kan förbättra både driftkostnad och hjälpa med hållbarhetsutveckling, genom att mer effektivt använda resuser.

Den här rapporten behandlar ett system som använder en databas som lagringsplats för loggar. En bra metod för att hämta ut dessa loggar saknades och databasdesignen behövde förbättras för sökningar i loggarna. En applikation för att hämta och söka i loggposter från databasen skapades. En undersökning om hur databasdesignen kunde förbättras genomfördes också. Båda delarna gjordes i ett projekt för att de hörde ihop. Applikationen skulle använda databasen. Då jag inte kunde göra vilka ändringar jag ville i databasen gjordes relativt begränsade ändringar i den. Större ändringar utreddes teoretiskt. Applikationen gjordes mot den existerande databasdesignen, med ett undantag: en vy lades till. Rapporten undersöker index och andra metoder att göra sökningar i en databas snabbare. En metod för att hämta data inom ett intervall i en databas utvecklades och den beskrivs i rapporten. Metoden söker efter all data som har värden på en kolumn som faller inom ett intervall och där databasen är ordnad, eller nästan ordnad, på den kolumnen. Metoden ger oexakta svar om databasen är nästan ordnad på den kolumnen. Den är snabbare än en motsvarande exakt sökning. / This report considers a system where a database is used as the back-end storage for logging. A suitable method for extracting information from the logs was missing and the database design needed an improvement for log searching. An application for extracting and filtering the logs was created. An evaluation of how the database could be improved was also performed. Both parts were done in one project since they were heavily connected. The application would use the database. Since I couldn’t make arbitrary changes to the database only relatively limited changes were made in practice. Larger changes were evaluated theoretically. The application was made against the existing database, with one exception: a view was added. The report handles indexes and other methods for speeding up database searches. A method for fetching data inside an interval in a database was developed and is described in the report. The method searches for all data where the value of a column is inside an interval and the database is ordered, or almost ordered, on that column. The method gives inexact answers if the database is almost ordered on that column. It is faster than a corresponding exact search.