Inspiration og forslag ønskes

Tags:    programmering

<< < 12 > >>
Hej Alle

Jeg står med en opgave foran mig, men jeg har ikke lige den fornødne indsigt i de forskellige værktøjer der findes idag.

På den baggrund beder jeg om lidt inspiration og gode forslag fra jer.

Opgaven går (i al sin enkelthed) ud på følgende.

Det er ikke en applikation der skal publiceres på nettet, en en applikation til internt brug.

Dagligt får jeg et antal kommaseparerede filer med oplysninger om forskellige produkter til videresalg. Filerne har forskelligt layout afhængig af sælgeren. Pt. modtager jeg 5 forskellige formater, men flere kan komme til senere.

Sælgerne har ofte de samme varer, og derfor ønsker jeg at lave et samlet varekatalog (SQL-database???), hvori jeg kan have ALLE oplysninger fra ALLE sælgerne om produkterne, velvidende at ikke alle sælgere giver de samme informationer; nogen er meget sparsomme andre det modsatte. Jeg forestiller mig at lave et varekatalog med en række vareinformationsfelter, som så udfyldes i det omfang en sælger giver oplysningerne.

Nå, det blev en lang historie. Kort sagt: en masse kommaseparede filer skal samles i en database dagligt.

Jeg forestiller mig et system, hvor jeg "trykker på en knap" og alle filerne oploades til databasen.

Hvilket værktøj vil I anbefale? SQL?

Når så databasen er loadet med data, skal jeg have et antal skærmbilleder, som jeg kan bruge til at kigge i databasen med, fx søge på et varenr, søge på alle varer fra en given sælger etc. Samtidig skal jeg kunne tilføje data til varekataloget, fx en kommentar om en given vare. Egentlig troede jeg at Access ville være det rigtige værktøj, men når jeg har spurgt i min omgangskreds klasker de sig på lårene og siger at Access er yt!

Hvad skal jeg så vælge?

En sidste ting som er vigtig. Jeg vil gerne placere denne applikation på en server jeg kan tilgå remote, fx fra sommerhuset eller lignende.

Komplicerer det billedet yderligere?

Jeg har en fornemmelse af at vi snakker ASP og SQL, men inden jeg går igang med at læse om disse værktøjer, kunne jeg godt tænke mig at høre jeres mening.

Hvis muligt vil jeg også gerne have nogle anbefalinger af gode bøger, websteder etc som kan hjælpe mig videre.

Der findes måske endda en freelance programmør, der kan løse opgaven!

På forhånd mange tak, jeg glæder mig til at høre fra jer.

NBP



11 svar postet i denne tråd vises herunder
0 indlæg har modtaget i alt 0 karma
Sorter efter stemmer Sorter efter dato
Selve web applikationen skulle være en smal sag at lave, det skulle ikke tage mange minutter (ASP.NET).

Problemet er filerne! Hvilke sql databaser har du til rådighed? Du skulle vel aldrig være så heldig at have en Microsoft SQL Server 2000 til rådighed på serveren? Der kan du lave en DTS pakke (kan læse dine filer ind i en fælles db) og vupti så har du din database. Problemet er sikkert alle de forskellige filformater, jeg kunne forestille mig at den ene sælger kalder vare navnet for "Marlboro Sorte Bukser" mens den anden sælger kalder det samme produkt for "Marlboro Bukser, Sorte" eller det der er værre. Problemet er at de mener det samme, men din database kan ikke se forskel. Selvom de skulle have det samme varenummer vil du få sådan noget her i din database:

1000 Marlboro Sorte Bukser
1000 Marlboro Bukser, Sorte

Alternativt skal du bede alle sælgere om at bruge det samme format, det er ikke sikkert de bliver så imponeret over.

Ellers skal der laves et program der kan læse hver enkelt format, og så må der aldrig ændres i det. Det er heller ikke holdbart.

(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto



Hej

Tak for det hurtige svar.

Jeg har principielt de værktøjer til rådighed som er nødvendige for at kunne løse opgaven (jeg har frie hænder til at købe).

Hvilke værktøjer vil du foreslå? Har du et bud på eventuelle priser?

Jeg er fuldt ud klar over problematikken med de samme varer med forskellige betegnelser; derfor skal jeg også kunne tilføje mit eget varenr via skærmbillederne, således at mit varenr bliver den primære nøgle.





Selve web applikationen skulle være en smal sag at lave, det skulle ikke tage mange minutter (ASP.NET).

Problemet er filerne! Hvilke sql databaser har du til rådighed? Du skulle vel aldrig være så heldig at have en Microsoft SQL Server 2000 til rådighed på serveren? Der kan du lave en DTS pakke (kan læse dine filer ind i en fælles db) og vupti så har du din database. Problemet er sikkert alle de forskellige filformater, jeg kunne forestille mig at den ene sælger kalder vare navnet for "Marlboro Sorte Bukser" mens den anden sælger kalder det samme produkt for "Marlboro Bukser, Sorte" eller det der er værre. Problemet er at de mener det samme, men din database kan ikke se forskel. Selvom de skulle have det samme varenummer vil du få sådan noget her i din database:

1000 Marlboro Sorte Bukser
1000 Marlboro Bukser, Sorte

Alternativt skal du bede alle sælgere om at bruge det samme format, det er ikke sikkert de bliver så imponeret over.

Ellers skal der laves et program der kan læse hver enkelt format, og så må der aldrig ændres i det. Det er heller ikke holdbart.

(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto





Og sælgerne skal ikke i stedet blot indtaste deres informationer i samme system?

Som jeg forstår dit interne system, så er det et "simpelt" system til at finde varer med, jeg forestiller mig ikke at det skal være ret meget andet funktionalitet end det du har beskrevet. Jeg tror det ville være billigere at lave en lille applikation der kan konvertere de komma separerede filer og indsætte dem i en database end at skulle købe en database server blot for dette. Så kan man klare det med en MySQL Server (gratis) og noget ASP.NET udvikling, og måske et lille program til at loade de filer ind i databasen (C# .NET). Det er mit umiddelbare bud på hvordan det kan klares således at omkostningerne holdes nede.


(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto



Jeg er desværre bange for at det ikke er så simpelt endda. Der kommer ca 30.000 varer totalt set. Nogen filer får jeg dagligt, andre ugentligt.

Systemet skal også "relativt nemt" (intet er nemt i denne verden:-)) kunne udvides med nye sælgere/leverandører.

Databasen skal senere danne grundlag for nogle udtræk til nye kommaseparerede filer, der kan uploades i et salgssystem.

/Niels

Og sælgerne skal ikke i stedet blot indtaste deres informationer i samme system?

Som jeg forstår dit interne system, så er det et "simpelt" system til at finde varer med, jeg forestiller mig ikke at det skal være ret meget andet funktionalitet end det du har beskrevet. Jeg tror det ville være billigere at lave en lille applikation der kan konvertere de komma separerede filer og indsætte dem i en database end at skulle købe en database server blot for dette. Så kan man klare det med en MySQL Server (gratis) og noget ASP.NET udvikling, og måske et lille program til at loade de filer ind i databasen (C# .NET). Det er mit umiddelbare bud på hvordan det kan klares således at omkostningerne holdes nede.


(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto





Så længe at filerne overholder de samme regler (komma separerede, antal kolonner) så skulle det ikke være noget problem. Hvor mange kolonner er der tale om? Er det også med datoer og med priser, antal... osv.

Findes der en database i forvejen dette skal ind i eller skal der installers en ny database server?

Der skal vel laves noget efterbehandling rent SQL mæssigt efterfølgende, således at eventuelle dubletter fjernes (almindelig data-scrubbing) og således at talformater og datoer passer til jeres behov? Samt omdøbe de underlige formater fold måtte indsætte til det der er valgt i web applikationen (altså det her med Marlboro bukser). Skal dette også håndteres af denne applikation eller findes der et separet værktøj til dette i forvejen?

(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto



Kan du give eksempler på disse filer, så vi kan se hvad forskellene på de forskellige formater er.

Hvis forskellene blot er række følgende tingende står, er det ikke så svært at lave det. Hvis det derimod er som i Brians eksempel, hvor der i det ene format er en seperat 'kolonne' til farven og i det andet er farven en del af navnet, så vil det blive kompliceret. Hvis du kan give eksempler på filerne, så vil det blive nemmere at hjælpe med at finde den bedste løsning.


Hilsen

Martin Dybdal (Dybber)



Alternativt kan de fleste databaser godt importere kommaseparerede filer direkte, spørgsmålet er om det format de har for nuværende er godt nok til at kunne indlæses i en database direkte, uden at blive transformeret først.

(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto



Jeg forestiller mig at jeg definerer fx 20 informationsfelter, fx
- eget varenr (tildeles af mig selv manuelt)
- leverandør id
- leverandør varenr
- varegruppe
- kort beskrivelse
- lang beskrivelse
- pris
- antal på lager
- etc.

Når jeg så får en fil fra en nuværende eller kommende leverandør, mapper jeg hans fil mod mit interface. Nogen leverandører kan måske levere 5 felter, andre 11 etc.

Hoved nøglen i varekataloget skal være mit eget varenr, som jeg påsætter manuelt første gang jeg får en given vare fra en leverandør. Når så filen kommer igen imorgen, overskriver den blot felterne, men IKKE mit varenr.

På den måde forestiller jeg mig at jeg dagligt kan få et overblik over alle mine leverandøres produkter med aktuelle priser og evt. lagertal.

Ligeledes vil jeg kunne søge i databasen efter "fx +Marlboro +bukser" og få alle hit der har delvis match, fx "Marlboro, sorte bukser" og "Marlboro, bukser sorte". Det er så bare min opgave at sikre at de to varer har samme varenr (mit eget varenr).

Jeg kan godt se at der kan blive et behov for at fx ensrette datoer etc inden upload til min database, men det må kunne løses.

Med hensyn til værktøjer og evt. isenkram, så er der indtil videre ingen begrænsninger. Det vigtigste er at løsningen bliver god.

Mange tak for jeres interesse indtil videre.

God weekend

Alternativt kan de fleste databaser godt importere kommaseparerede filer direkte, spørgsmålet er om det format de har for nuværende er godt nok til at kunne indlæses i en database direkte, uden at blive transformeret først.

(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto





Jeg synes, hver gang jeg tænker over hvordan det skal gøres, så vender jeg altid tilbage til det faktum at jeg ville kunne lave denne løsning (database tingen) rimelig hurtigt på en SQL Server 2000, men det forudsætter en SQL Server - og den er ikke just gratis. Jeg ved godt du siger at der ikke er begrænsninger, men en SQL Server er en stor investering, som jeg helst vil have at du er foruden, hvis det er muligt at slippe for det. Jeg har bygget denne type dataware houses mange gange tidligere og er tilmed Microsoft Certificeret på netop SQL Serveren, hvorfor jeg har en naturlig præference for netop denne. Jeg har en lokal installation af SQL Serveren kørende her hos mig, så jeg kan godt lave en løsning, som kan testes og se om det er det værd at investere i en SQL Server. Herefter kommer så vedligeholdelsen af systemet.

* Administratoren af systemet (dig?) skal have at vide hvordan man tilføjer en ny leverandør, dette sker inde i SQL Serverens ETL værktøj, som er hele grundstenen i dette.

Jeg vil lige sætte hjernen i blød her over weekenden og forhøre mig rundt omkring om hvordan dette eventuelt ville kunne gribes an, uden at skulle købe en SQL Server 2000.

(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto



Hej Brian

Jeg har kigget lidt på priserne på en SQL Server 2000, og du har ganske ret. Den er godt nok dyr!

Hvis jeg er sikker på at det er den rigtige løsning, kunne det også godt forsvares at investere i sådan en softwarepakke, men jeg er lidt bekymret for om det er for kompliceret, hvis jeg selv skal starte fra bunden. Hardwaren kommer jo oveni.

Risikoen for at pengene er spildte er trods alt til stede!

Jeg vil nok føle mig bedre tilpas med en erfaren mand ved min side til at lave sådan et system.

Trods de sparsomme oplysninger du har, er du så i stand til at gætte på hvor lang tid det vil tage at udvikle sådan en applikation?

Jeg synes, hver gang jeg tænker over hvordan det skal gøres, så vender jeg altid tilbage til det faktum at jeg ville kunne lave denne løsning (database tingen) rimelig hurtigt på en SQL Server 2000, men det forudsætter en SQL Server - og den er ikke just gratis. Jeg ved godt du siger at der ikke er begrænsninger, men en SQL Server er en stor investering, som jeg helst vil have at du er foruden, hvis det er muligt at slippe for det. Jeg har bygget denne type dataware houses mange gange tidligere og er tilmed Microsoft Certificeret på netop SQL Serveren, hvorfor jeg har en naturlig præference for netop denne. Jeg har en lokal installation af SQL Serveren kørende her hos mig, så jeg kan godt lave en løsning, som kan testes og se om det er det værd at investere i en SQL Server. Herefter kommer så vedligeholdelsen af systemet.

* Administratoren af systemet (dig?) skal have at vide hvordan man tilføjer en ny leverandør, dette sker inde i SQL Serverens ETL værktøj, som er hele grundstenen i dette.

Jeg vil lige sætte hjernen i blød her over weekenden og forhøre mig rundt omkring om hvordan dette eventuelt ville kunne gribes an, uden at skulle købe en SQL Server 2000.

(¯`·._.·[Brian Hvarregaard]·._.·´¯)
Praesto et Persto





<< < 12 > >>
t