vi er her !!!

02120

DifferentielGPS
home

MySQL - Server

Nødvendigt Software

Løsningen forudsætter installationen af de følgede 2 stykker software på klient maskinen:

  • MySQL databasen [i0503]
  • MySQL JDBC Driver [i0502]

Installation og opsætning af MySQL forudsættes bekendt af brugeren. Ligeså mht MySQL JDBC driveren.

Brugerkonto

Der skal i MySQL opsætningen være defineret en brugerkonto til brug for programmet. Det er ikke nødvendigt at oprette databaserne - det er nok at oprette brugerkontoen og indtaste informationerne om denne i programmet.

I testfasen benyttedes følgende kommandoer til at oprette brugeren:

grant usage  on *.* to 'dGPS'@'%' identified by 'dGPS' ;
grant create on *.* to 'dGPS'@'%' ;
grant delete on *.* to 'dGPS'@'%' ;
grant index  on *.* to 'dGPS'@'%' ;
grant insert on *.* to 'dGPS'@'%' ;
grant update on *.* to 'dGPS'@'%' ;
grant select on *.* to 'dGPS'@'%' ;

Brugernavn og password skal selvfølgelig tilpasses den enkelte installation.

Det er nogen heftigt potentielle sikkerhedsriskoer ved ovenstående tilladelser. Der kan:

  • skabes hele databaser - ikke bare tabeller i en eksisterende database
  • potentielt skaffes adgang til samtlige databaser på serveren - og disse kan modificeres
  • kobles op til databasen fra enhver maskine

Det bør derfor nøje overvejes hvilke privilegier denne bruger skal have samt hvilke urler der vil være aktuelle. Et alternativ er selvfølgelig at håndkode de nødvendige databaser samt tabeller og så fjerne dette afsnit fra programmet. Vi har valgt denne løsning fordi det gjorde administrationen af at oprette databasen og tabellen lettest mulig for slutbrugeren.

Databasens struktur

Programmet benytter en database med den følgende struktur:

mysql> describe data;
+----------------+--------------+------+-----+---------------------+-------+
| Field          | Type         | Null | Key | Default             | Extra |
+----------------+--------------+------+-----+---------------------+-------+
| opdateret      | timestamp    | YES  |     | CURRENT_TIMESTAMP   |       |
| oprettet       | timestamp    | YES  | MUL | 0000-00-00 00:00:00 |       |
| scaleFactor    | int(11)      | YES  |     | NULL                |       |
| udre           | int(11)      | YES  |     | NULL                |       |
| satelliteId    | int(11)      | YES  | MUL | NULL                |       |
| iod            | int(11)      | YES  |     | NULL                |       |
| pseudorangeC   | double       | YES  |     | NULL                |       |
| rangeRateC     | double       | YES  |     | NULL                |       |
| tidsstempel    | bigint(20)   | YES  | MUL | NULL                |       |
| modifiedZCount | double       | YES  |     | NULL                |       |
| stationID      | int(11)      | YES  |     | NULL                |       |
| sequenceNo     | int(11)      | YES  |     | NULL                |       |
| device         | varchar(32)  | YES  |     | NULL                |       |
+----------------+--------------+------+-----+---------------------+-------+
13 rows in set (0.43 sec)

De første 2 felter er til internt bogholderi ved vedligeholdelsen af databasen. De resterende felter er data fra satelitterne, der er blevet tidsstemplet og associeret med en bestemt satellit. Datatyperne afspejler direkte enten det de skal bruges til (opdateret og oprettet) eller de datatyper, som vi får, når data fra kilderne afkodes.

En mærkværdighed, der observeredes, var, at hvis man ønskede at starte forfra med friske database strukturer (hvilket blev nødvendigt for os efterhånden som vi gradvist tilpassede tabellen til dens endelige udformning), så var det ikke nok bare at droppe databasen - man skulle også først droppe tabellerne i den først; ellers fik man den gamle struktur på tabellerne igen når de blev genoprettet selvom man sendte en ny og opdateret struktur. Et eller andet sted i systemerne lå der åbenbart en kopi af tabellernes struktur i en cache.


home