Closed turnipsoft closed 6 years ago
Er ElasticSearch med en model der passer direkte med hvad applikationen ikke oplagt når nu der ikke skal skrives nogen steder? :)
Jo det er lige præcis ES der er i søgelyset, men faktisk er det ikke så vanvittig stort problem, for selv om man parser on the fly, går det egentlig ret stærkt.
Men der er andre fordele ved at gemme de parsede regnskaber i ES og det er selvfølgelig at man kan søge i dem. Men, det er så der hvor der faktisk findes et XBRL indeks allerede, men det er ikke offentligt p.t.
Ellers er det jo en glimrende lejlighed til at lege med f.eks. Redis
Ja hvis ikke der egentlig er noget større søgebehov, er Redis vel lidt mere to-the-bone? :) har ikke rodet så meget med det, men ville da være sjovt at prøve
Det kunne også være firebase, så har man data i skyen med det samme og det kunne være meget sjovt at rode med en app der anvender firebase til at hente data ud. Hele den del at man kan subscribe fra apps til firebase er meget cool.
Den har jo slet ikke samme muligheder for søgning så det skulle kun være for at kunne cache en virksomheds regnskaber uden behov for at søge i dem.. Der vil Elastic trods alt være bedre.
Kan dog stadig godt lide bare en "mindre" memory cache som purges løbende
Lukker, out of scope p.t. laver et nyt issue, hvis det er noget vi vil have på senere
postgres er lidt ufkleksibel i forhold til at datamodellen ændres ofte og det ville egentlig være bedre med en dokumentdatabase.
Men kravene er samtdig at det skal være en dokumentdatabase som ikke kræver for meget ram da løsningen skal kunne køre på små servere med meget lidt ram, og der kan jo potentielt være ret meget data hvis man snakker samtlige regnskaber.
Lige meget hvad skal hele DB lag skærmes så man køre mod forskellige providere, derfor lægges der op til at der beholdes en postgres model, men at man kan gå over på en Elastic model, primært af hensyn til ERST