Hvilke database-fundament er brukervennlig/anvendelig?

[G]

1. Jeg kan ikke alt for mye. Har lett litt på internett etter løsninger.
   
2. Det er en skog av løsninger.
   
3. Det kreves diverse forutsetninger av designere og brukere.
   
4. Eksempelvis må man i noen fundamenter kunne programmering.
   

Jeg er ute etter åpne løsninger, men er villig til å betale noen kroner (innen rimelighetens grenser (helst under kr 5000) for å slippe å dykke for dypt i avanserte ting som programmering.

 

Skal brukes til avansert database i hobbysammenheng, hvor antall typer felt og sammenveving og spørringer kommer til å kreve litt. Det er ikke minus om det er åpninger for webpublisering og interaksjon.

 

Så må man også ta hensyn til hvilken databasemodell man baserer det på:

 

http://en.wikipedia..../Database_model

 

Det bør være også være et visuellt brukergrensesnitt for konstruksjon og design av databasestrukturene. Det er her jeg ønsker å slippe å måtte kunne programming.

 

Jeg tar det ellers for gitt at det er et visuellt brukergrensesnitt til input av data.

 

Noen forslag?

 

Andre alternative forslag som koster over kr 5000,- ?

Endret 12. mars 2013 av G

[quantum]

Grafisk modellering av databasen fins det ganske god verktøystøtte for, f.eks. SQL Power Architect og mange andre. Men det er uansett ikke der programmeringsutfordringen ligger, og jeg har vel egentlig ikke noe superforslag for deg. MS Access kanskje, her kan du komme et stykke uten å kunne programmering, men du må isteden kunne MS Access... Med litt større datamengder og avanserte spørringer vil MS Access gå som sirup hvis du ikke kobler den mot en ordentlig relasjonsdatabase.

 

De fleste relasjonsdatabaser kommer også med egne administrasjosnverktøy, men disse er ment til å opprette brukere, tabeller, skjemaer osv, og du har sjelden støtte for annet enn å redigere data i et tabellformat a'la excel, altså ikke noe særlig mulighet til å bygge opp et mer brukervennlig gui.

[G]

Siden jeg er ganske grønn. Så har jeg lett en del. Fant f.eks. denne nyheten:

 

http://www.jedox.com/en/about-jedox/news/jedox-now-available-in-two-versions-base-and-premium.html

 

Vil jeg kunne bruke dette som en database. Der det nevnes regneark-støtte. Men, er dette et feilsteg av meg å forsøke Jedox i april 2013? Er sånn i tvil.

 

En annen variant som har trukket oppmerksomheten min er Alpha Five:

 

http://www.alphasoftware.com/

 

Men igjen er jeg i tvil om det er tingen.

[quantum]

Vet lite om dine behov, så det blir vanskelig å svare på denne, men generelt ser det ut som jedox er et BI-produkt, altså "rammeverk" for avansert analyse av store datasett, du kan sikkert lese om OLAP på wikipedia selv. Jedox er nok ikke et verktøy for å utvikle applikasjoner.

 

Apha Five er et 4.generasjons/RAD verktøy, og uten å egentlig vite hva jeg snakker om tror jeg den ligger nærmere det du er på jakt etter. Men, det er alltid begrensninger i hva du kan få til med et slikt RAD-verktøy. Dette verktøyet kan du jo bare laste ned og prøve i 30 dager så kan du se selv hva du får til. Viktig å sjekke hvaslags hjelp og støtte du kan få på nett når du bruker et slikt verktøy som kanskje ikke er så veldig utbredt.

[G]

Er ikke sikker på om jeg vil lykkes. Men, har lyst å begynne å leke litt med hobbyen.

 

Altså ønsker jeg å katalogisere travresultater (meget kjedelig oppgave). For så å analysere dem med bindinger og spørringer.

 

Har lite erfaring med database, annet enn lett innføring. Så jeg er en slags newbie. Access hadde egentlig en trang fødsel, og jeg har sett hvor begredelig det grensesnittet var på 90-tallet. Programmere ligger kanskje ikke for meg nå, eller enda. Har fått med meg at database-programmering er noe kjedelige greier fra en som var spesiellt interessert i generell programmering.

 

Etter en liten katalogiseringsrunde av data som eksempelvis:

 

https://www.rikstoto...-03-12|t:BJ|o:0

 

Og ytterligere data som knyttes mot løpet hesten deltok i:

https://www.rikstoto...Baneprogram.pdf

 

De to kildene overlapper på noe informasjon, og utfyller hverandre på andre måter. Etterhvert kunne jeg tenkt meg å:

 

Forsøke en slag form for spørring. Dette har potensiale til å bli så avansert som fantasien om hva man ønsker å oppnå når opp til.

 

1. Det er fare for et evighetsprosjekt

2. Man lærer kanskje noe på veien, som en bonus

3. Man vinner kanskje en gevinst en eller annen gang med kanskje 10 % hjelp i egen database

 

4. Med flere muligheter av følger

 

Trav spiller jeg allerede på, så det blir lite forskjell sånn sett. I dag roter jeg fælt rundt i regneark med oppgaver som kanskje en database ville ha løst for meg med litt forberedelse etter datainnhøsting på 5 sekunder eksempelvis. Sortering og kalkuleringer.

 

Oppdatering:

Utover de to lenkene over, så finnes det ytterligere kilder til informasjon for ting som Løp og ting som Hester, samt for Kusker:

 

Eksempler:

Løp:

http://www.travsport...03.2013&track=2

 

Hest:

http://www.travsport...&sokId=30052753

 

Kusk:

http://www.travsport...us=0&sokId=2209

 

Kusk prestasjoner i 2013:

http://www.travsport...us=0&sokId=2209

(ok, den var lik lenken over. Da år 2013-lenken var javascript, må man manuellt trykke på årstallet 2013, for å få opp et annerledes vindu)

 

Uten å skulle dra deg for langt inn i materien, så ser du at det er et hav av data å samle, dersom man skulle bry seg om alt. Man får begynne forsiktig og så utvide etter hva man selv evner.

Endret 12. mars 2013 av G

[quantum]

Det er sikkert et hav av data å legge inn, men datastrukturen du skal lagre i ser ikke kompleks ut, sagt veldig forenklet, det er ikke antal rader men antall kolonner som avgjør kompleksiteten. Det betyr igjen at du kanskje kan bruke et "trylleverktøy" (RAD) som Apha Five, eller Access for den saks skyld, og få et akseptabelt resultat.

[G]

Er database-delen i et BI-verktøy ubrukelig? Eller blir det bare mye støy fordi det er skreddersydd til andre spesielle oppgaver?

 

Jeg er jo ikke uenig i at det ser lite kompleks ut. Men hadde håpet at det fantes trylleverktøy som åpnet for mye forskjellig på en enkel måte, men samtidig profesjonell. Jeg vil jo nødig bygge databasen mer enn 1 gang.

 

Likevel når du ser informasjonshavet som ligger der, så er kanskje ikke katalogiseringen særlig kompleks. Jeg tror likevel det oppstår mange flere kolonner enn hva du ser for deg. Det ligger masse fin-informasjon sånn halvt bortgjemt mellom alle sidene jeg har lenket til.

 

Samt kanskje egne betraktninger og opprettelse av et slags poengsystem. Så ønsker jeg å trylle fram fornuftige spørringer. Alt-i-alt så er jeg supergrønn.

 

Har kikket litt og sett at det finnes et hav av modeller å velge mellom. Noen av disse har fleksibilitet, og får jeg det med på kjøpet?

Endret 12. mars 2013 av G

[Terrasque]

http://www.openoffice.org/product/base.html kanskje?

[quantum]

Er database-delen i et BI-verktøy ubrukelig?

Databasen er vel oftest der fra før av, og så brukes BI-verktøyet som et tillegg på toppen, uten egen database. Tror ikke egentlig det gir så veldig mye mening å lukte på et sånt produkt før du har stanga hodet i taket med en vanlig database og vanlige spørringer.

[quantum]

Har kikket litt og sett at det finnes et hav av modeller å velge mellom. Noen av disse har fleksibilitet, og får jeg det med på kjøpet?

Disse modelltypene henger vel sånn mer eller mindre sammen med tilhørende databasetyper, ser ut som de også blander begrepa litt. Eksempelvis er en eller annen form for relasjonsmodell ment å implementeres i en relasjonsdatabase, en hierarkisk datamodell i en hierarkisk database og så videre. Dog er ikke dette helt hugget i stein, en veldig vanlig kombinasjon er å ha en objektorientert domenemodell implementert i et objektorientert programmeringsspråk, og så bruke en ORM (Object-relational mapper) for å persistere i en relasjonsdatabase.

 

De fleste databaser er relasjonsdatabaser, punktum. I de senere åra har det vært en del vind rundt andre alternativer, under samlebegrepet NoSQL, hvor andre behov har vært i fokus, f.eks. oppslagshastighet i enorme datamengder på bekostning av en del andre egenskaper en vanligrelasjonsdatabase har (ACID), dokumentdatabaser mv. Det fins helt sikkert en utmerket artikkel om NoSQL på Wikipedia, men du vil temmelig sikkert ha størst nytte av en helt vanlig relasjonsdatabase til ditt prosjekt, og det blir da også en eller annen form for relasjonsmodell du skal bruke for å modellere databasen din. F.eks. en ER-modell.

 

Fordelen med OO Base - som ble foreslått ovenfor her - er at den kommer med en mer eller mindre ekte relasjonsdatabase i bånn (HSQL), og kan brukes i kombinasjon med en rekke andre enda kraftigere relasjonsdatabaser, mens Access som jeg - mitt fe - antydet som et forslag kommer med et slags odde misfoster som til forveklsing kan ligne en relasjonsdatabase. Dog kan Access kobles mot andre og kraftigere relasjonsdatabaser om det behøves.