Hjælp til salg (Ikke internet)

Sv.: Valg af database

Mikkel Mikjær Christensen — Sun, 20 Jan 2008 22:42:21 GMT

Det er noget du skal lade de konsulenter du ansætter udarbejde for dig, der var snak om at lave 500 kolloner brede tabeller, det er noget vås og et klart tegn på en fejl i databasens design.

I har to muligheder,

a: Hyr en konsulent til at afklare de indledende spørgsmål og udvikle produktspecifikation, vælge teknologier og hyre enten udviklere eller en virksomhed til selve udviklingen og efterfølgende stå for kommunikationen med denne.

b: Hyre en ekspertvirksomhed indenfor enten ASP/C#.Net eller PHP(i forbindelse med begge disse sprog kunne min virksomhed være en mulighed) andre (imho uegende) bud kunne være Perl, Jsp eller C++/C/Cgi, og lade dem starte med at udvikle specifikationen og efterfølgende udvikle softwaren.

Fordelen ved A er at i behøver minimal indsigt i det tekniske for at gennemføre udviklingen, men prisen bliver højere idet i skal betale både for udviklerne og konsulenten. Ved mulighed B vil det være nødvendigt for jer at tage stilling til hvilken virksomhed i vil hyre (hvis bare i vælger enten PHP eller .NET og samtidig vælger en virksomhed med meget dygtige folk der IKKE bassere deres løsning på standardsoftware/løsninger er i nogenlunde sikre) men tilgengæld er det billigere og mere effektivt end A.

DB2: Databasernes porche

Oracle: Kan alt, Stor og voldsomt dyr.

Mssql: Kan det meste, stor og dyr.

Postgresql: Kan alt, billig

Mysql: kan det basale og er uhyre billig.

Jeg vil klart anbefale en af de sidste 3.

Sv.: Valg af database

Jesper F — Sun, 20 Jan 2008 22:09:57 GMT

Libbert:
Formodningen er at den database vores projekt kræver er forholdsvis billig at lave når omfanget ikke er større

Det er ikke mængden af poster i en databasetabel, der evt. gør en database avanceret. Det er komplekse relationer mellem tabellerne eller utradionelle tabelopbygning, der kan gøre det svært at få det helt rigtigt. Simple databaser er hurtige at opbygge. Det der kommer til at tage tid i jeres tilfælde er frontend-opbygningen.

Libbert:
Vil meget gerne have en grafisk brugerflader til at tilføje data

Libbert:
Til dette er en access lignende database umiddelbar

Der er mange muligheder for at få en grafisk brugerflade til databsen. I skal tænke nøje over hvilke krav I har til dette. Vil man helt simpelt kunne opdatere tabellerne i databasen findes der masser af simple måder at få en automatisk genereret brugerflade.

Accessdatabaser er ikke egnet til hjemmesider mere mere end nogle få besøgende. Men husk på at programmet MS Access ikke er databasen i sig selv. Det er et databaseadministrationsprogram og kan sagtens bruges til at administrere forskellige typer af databaser også samtidig fra samme Accessfil. Access "medfødte" databaseformat er jo .mdb-filerne som bruger JET-databasemotoren. Men selv om I bruger Oracle, MySQL, MSSQL eller andre kan man altid forbinde til tabellerne i disse databaser (som oftest ikke har særligt veludviklede brugerflade) og dermed admninstrere jeres database via den velkendte Accessbrugerflade.

Access er et godt værktøj til relativ hurtigt udvikling af brugerflade. Mange ting kan man også til at fungere med browseren som brugerflade, men det tager typisk længere (og bliver dermed dyrere, tænk over hvor vigtig det er for at jer at kunne arbejde alle steder fra). Hvis det drejer sig om et begrænset antal medarbejdere får de selvfølgelig bare alle kopier af Access-frontenden og kan dermed med en avanceret brugerflade alle tilgå den samme backend-database.

Ang. valg af databasetype mener jeg at MySQL og MSSQL er de mest oplagte. Jeg kender ikke Oracle men hvis man skal have hosted sin database er de to første lang nemmere at komme til. De er begge meget robuste og scalerbare og valget skal nok ligeså meget afhænge af hvilken database jeres valgte programmører er vant til at programmere op i mod. Ofte bruges der PHP med MySQL og ASP(.NET) med MSSQL men alt kan lade sig gøre.

Libbert:
For hvert selskab er der i skrivende 500 informationer i form af tekststrenge og tal

Mange databaser tillader ikke et uendeligt højt antal kolonner i en database og det lyder som om I skal have en vertikal struktur i stedet for horisontal i jeres tabel med virksomhedsinformation.

Libbert:
Forstillingen er at den bedste løsning er at "fodre" database med rådataen i excel form og behandle denne data her

Ofte foregår reel databehandling af kompleks art bedre i regneark, men det kommer an på type og mængde.

Libbert:
der vil løbende tilføjes nye priser

Der kan udvikles brugerflade til jer som automatiserer jeres import så det bliver så nemt for jer som muligt at opdatere.

/ Jesper Fjølner

www.medicinskedatabaser.dk

Sv.: Valg af database

Anonymous — Sat, 19 Jan 2008 10:50:02 GMT

Hej Michael,

Hvis du vil have en af verdens mest stabile databaser, vil jeg helt klart anbefale Oracle (www.oracle.com).
Der findes en gratis version med op til 4 gb data, hvilket er rimeligt meget.
Hvis du mangler mere information, om Oracle - eller er intresseret i webhosting/databasehosting er du vekommen til at kontakte mig på jh@webname.dk

Sv.: Valg af database

Ronnikc — Sat, 19 Jan 2008 10:25:07 GMT

Jeg vil vurdere at det nok er nemmest og billigst at få udviklet det hele til en webplatform med en frontend og en backend. Dvs. at som ejere/administratorer har fuld adgang til alle funktioner i backenden men at en del af funktionaliteten ikke fungere på frontenden til brugerne/kunderne. Derfor er der rent økonomisk ikke den store forskel på om det er realtime opdateringer eller ej - tværtimod vil det nok kun blive dyrer at lave et differentieret system.

Skal du til at have lavet databasen i Indien, kodet en backend som alm. windows program, kodet frontend af et firma i dk så får du en så fraktioneret løsning så der nemt kan opstå en masse problemer. Med mindre altså du taler om at få fyldt databasen ud med data? Så kan det måske godt betale sig, men det er noget andet end at få lavet selve database hierakiet.

Det vil aldrig kunne betale sig at få lavet databasen i udlandet - Lad dem som skal kode projektet lave databasen også. Kodningen af website og database hænger meget sammen og kræver at det spiller sammen 100% samtidig skal webudvikleren have mulighed for løbende at kunne tilpasse såvel kode som database hvis der undervejs opstår behovet derfor.

Umiddelbart lyder behovet ikke til at være større end at en mysql database fint kan klare det.

Sv.: Valg af database

ecentralen — Sat, 19 Jan 2008 10:24:53 GMT

Hej Michael, Jeg arbejder ofte med store databaser (banksystemer), og er vant til kompliceret behandling af data. Du er velkommen til at henvende dig til mig - se kontakt. Jeg har designet store databaser (netop banksystemer). Jeg har endvidere forbindelser til outsourcing (Indien er ikke et godt sted).

Valg af database

Libbert — Sat, 19 Jan 2008 10:08:14 GMT

Hej

Jeg søger efter en vurdering af hvilke database løsning der vil være bedst i min situation. Jeg er medejer af en ny startet virksomhed, som indenfor de næste 6-12 måneder skal lancere en hjemmeside. Siden er baseret på en database af informationer omkring en række virksomheder. De tilbud vi har fået for hele projektet har ligget meget højt. Vi er derfor i overvejelser om hvorvidt vi kunne outsource udviklingen af databasen til Indien.

Formodningen er at den database vores projekt kræver er forholdsvis billig at lave når omfanget ikke er større. Selve siden design og setup skal laves af et dansk selskab. Det skal siges at jeg ingen viden omkring programmering har, men har identificeret at der kan være følgende problemstillinger der skal tages højde for (der findes sikkert mange flere):

Problemer ved at en 2. part laver websiden i forhold til databasen.

Hastigheden af hjemmesiden afhænger af den underliggende database.

Vil meget gerne have en grafisk brugerflader til at tilføje data, samt generel anvendelse i hverdagssituationer (informationssøgning). Til dette er en access lignende database umiddelbar, men spørgsmålet er når databasen skal bruges til en web site (daglige opdateringer).

Jeg har forsøgt at beskrive omfanget af databasen.

Virksomhedsdatabase med op mod 500 selskaber. For hvert selskab er der i skrivende 500 informationer i form af tekststrenge og tal. Dertil er der en analyse af priser fra selskaber som i øjeblikket gennemgår en simpel data behandling i Excel. Forstillingen er at den bedste løsning er at "fodre" database med rådataen i excel form og behandle denne data her. Omfanget er på kort sigt omkring 700-1000 priser, men der vil løbende tilføjes nye priser som skal enten erstattes den oprindelige eller tilføjes databasen. Dvs at databasen med tid ville blive større i sin omfang. Ved behandling menes simple datamanipulering, som plus, minus, gange, divider.

Det skal bemærkes at alt data ikke skal på hjemmesiden og at der ikke er tale om realtime opdateringer.

Det største problem lige nu er, at det er svært at finde en uvildig person til at vurdere hvilken løsning der er bedst for vores projekt. Det er af denne grund jeg skriver på her på Amino.

Venlig hilsen

Michael