[Delphi] Facturensysteem

[Verwijderd]

Ppl,

Ik heb een opdrachtje (mn eerste) binnen gekregen waarbij ik een grote database moet gaan ontwikkelen waarbij dus naam, adres enz enz. in gezet kan worden. Daarbij moet ook het aantal bewerkingen per factuur ingezet worden.

Het is namelijk een bedrijf dat de afwerking van een media product (lees: posters e.d.) doet. Dat kan zijn het snijden of vouwen van een product waar dus een bepaald bedrag aan verbonden is.

Nu is mijn vraag hoe ik dit het beste kan doen. Mijn idee is om dit met behulp van records te gaan doen, die in een *.dat bestand doen en het zo uit te lezen. Maar stel nou dat het een bestand wordt van 200000 records en je moet er 1 hebben. Dan duurt het natuurlijk vet lang om dat te zoeken.

Mijn vraag is nu of iemand dit op een handige manier kan oplossen. Ik hoef geen code's e.d. te hebben maar gewoon een goede opzet van hoe ik het beste kan beginnen.

[supakeen]

Indelen in een .dat bestand per dag

[Verwijderd]

Hm, wil je niet afzeiken ofzo, maar zoals ik het lees, is het voor het bedrijf het beste
dat ze het door iemand anders laten doen.
Maar hier wat tips (ik houd me ff in):
- Lees wat boeken over software ontwerp/ontwikkelen
- Lees wat boeken over databases/database ontwerp
- Of besteed het uit aan iemand die verstand heeft van software ontwikkelen/database ontwerp

Als je met zo'n opdracht nog niet eens weet waar te beginnen, zal ik maar uitkijken met contracten aan te gaan. Want de kans is natuurlijk groot dat (als je al wat inelkaar gefutseld krijgt) het niet goed werkt en/of niet voldoet.

Maar in ieder geval success.

[ Voor 3% gewijzigd door Verwijderd op 06-12-2002 20:17 ]

[LordLarry]

Waarom geen database? Die zijn daarvoor bedoelt...

[Verwijderd]

Verwijderd schreef op 06 december 2002 @ 20:16:
Hm, wil je niet afzeiken ofzo, maar zoals ik het lees, is het voor het bedrijf het beste
dat ze het door iemand anders laten doen.
Maar hier wat tips (ik houd me ff in):
- Lees wat boeken over software ontwerp/ontwikkelen
- Lees wat boeken over databases/database ontwerp
- Of besteed het uit aan iemand die verstand heeft van software ontwikkelen/database ontwerp

Als je met zo'n opdracht nog niet eens weet waar te beginnen, zal ik maar uitkijken met contracten aan te gaan. Want de kans is natuurlijk groot dat (als je al wat inelkaar gefutseld krijgt) het niet goed werkt en/of niet voldoet.

Maar in ieder geval success.

Iedereen begint ergens. En ik ken die baas gewoon persoonlijk en hij weet wat hij aan me heeft. Ik wil het iig wel zo doen dat mijn opzet goed is. Dat er niet later achter kom van, hee dit had je veel makkelijker kunnen doen. Nee, daarom zou ik graag wat tips willen weten van hoe ik dit het beste aanpak.

[_Thanatos_]

Als je het al over 200.000 records hebt, kun je het beste gewoon met je delphi progsel vertrouwen op een SQL server. MySQL voldoet misschien zelfs al. Dat scheelt een hoop denkwerk van hoe de database in elkaar moet steken, omdat je dat aan de SQL server overlaat, met dat je zeker weet dat het goed werkt.

[Verwijderd]

Verwijderd schreef op 06 December 2002 @ 20:39:
[...]


Iedereen begint ergens. En ik ken die baas gewoon persoonlijk en hij weet wat hij aan me heeft. Ik wil het iig wel zo doen dat mijn opzet goed is. Dat er niet later achter kom van, hee dit had je veel makkelijker kunnen doen. Nee, daarom zou ik graag wat tips willen weten van hoe ik dit het beste aanpak.

Ok, maar heb je al enige ervaring met databases ??

Je moet inderdaad gaan denken aan bv. MS-SQL (kost veel centjes), of eventueel interbase/firebird (is gratis) , ook mysql is een redelijk goede database (ben ik niet zo bekend mee), om je data in op te slaan. Heb je al een idee wat je allemaal gaat opslaan aan data ? en de onderlinge relatie van die data ?
Dan komen er nog indexen, unique-keys etc. etc. om de hoek kijken.

Dat moet je dus eerst allemaal goed opzetten voordat je aan 't programmeren begint.

[Just_a_Gamer]

je hebt ook nog oracle-database. En als je je systeem goed kan opzetten dan kan je het later nog gebruiken voor andere doeleinden ( andere registratie systemen )

[whoami]

Zoals reeds gezegd: al die info opslaan in een *.dat bestand is geen goed idee. Dat kan makkelijker; nl. door gebruik te maken van een databank: MySQL, PostgreSQL, Sql - Server, MSDE (=gratis gestripte SQL Server, maar die moet je enkel gebruiken als je max. 5 concurrent connections hebt).

Ik zou zeker eens naar dat databank-gedoe kijken, en leer dan alvast eerst eens hoe je een goed datamodel moet opzetten: hier bijvoorbeeld. (In de P&W FAQ staan er nog een paar andere interessante links).

[OZ-Gump]

Eerlijk gezegd ben ik het wel met maui71 eens wanneer hij zegt dat je niet overkomt als iemand die snel een solide programma in elkaar draait waarmee gefactureerd kan worden.
Kijk eens rond wat voor database-platforms er zijn en wat jij denkt nodig te hebben. MS-SQL is bijvoorbeeld inderdaad heel duur. Je zou een opzet voor de database kunnen maken in Access en kijken hoe dat draait. Als vervolgens blijkt dat het niet voldoet, kun je die database upsizen naar een SQL-database. Maar misschien is die Access-db wel voldoende. En dan scheelt dat in ieder geval al een hoop geld voor de database waar je op draait. (Je hebt dan namelijk bij de klant geen access-licentie nodig).
Het lijkt me echter toch wel verstandig als je nog eens goed nadenkt over of je dit wel wil doen. En over hoe lang je ermee bezig denkt te zijn. En denk je aan ondersteuning? Als het fout gaat kent de baas je namelijk ook...

[whoami]

[nohtml]

Verwijderd schreef op 06 december 2002 @ 20:39:
[...]


Iedereen begint ergens. En ik ken die baas gewoon persoonlijk en hij weet wat hij aan me heeft. Ik wil het iig wel zo doen dat mijn opzet goed is.

Iedereen begint ergens ja.... Maar je moet ook niet eerst leren lopen vooraleer je gewoon kunt gaan. Normaal gezien begint men bij simpele dingetjes, ipv direct een applicatie te maken voor een bedrijf.

[Elissen]

Als ik jou was zou ik eerst 'droog' gaan oefenen. Maak eerst eens voor jezelf een adresboekje met een Access database. Laat het programma ook bijvoorbeeld een adresboek/rapport genereren.
Dit sluit aan met hetgeen wat je wilt gaan doen (dataopslag ed). Op deze manier krijg je eerst inzicht in het maken van zoiets zodat je ook een beter idee hebt hoe je aan een groter project moet gaan beginnen.

[FendtVario]

Is wel een leuke opdracht maar misschien iets te groot om mee te beginnen. Bij een factureringsysteem komt meer kijken dan je nu denk, daarnaast moet het goed werken, gegevens mogen niet verloren gaan, je programma moet duidelijk zijn (en hierbij niet alleen de executable, maar ook de code). Je moet eerst documenteren voordat je gaat bouwen.

Als je een bestandje met records gebruikt moet je zelf de link leggen tussen klant, factuur en die dingetjes die met het produkt gedaan moeten worden. Een relationele db kan dit veel beter.

Heb het er nog eens over met dat bedrijf, ik neem aan dat ze resultaat willen zien en niet jaren kunnen wachten. Als je nu denkt dat het niet gaat lukken, zeg dan dat je het niet doet. Maar maak het dan voor jezelf om te kijken of het wat was geworden, zo doe je een hoop ervaring op.