Stuart_Johnson
asked on
Sort Records
I have started writing a app which saves information on our customers at work and saves the data as a record to disk. It is supposed to be tracking our service calls and then we can review, at the end of a twelve month period, how many calls a particualar client has made and what the call involved.
The record is "indexed" by client number. What I want to do
is scan through the file, sort it and remove any duplicates at the same time. The most important part is just sorting - by client number.
Any help would be appreciated.
The record is "indexed" by client number. What I want to do
is scan through the file, sort it and remove any duplicates at the same time. The most important part is just sorting - by client number.
Any help would be appreciated.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If you don't want to use the Paradox DB method...here's a pointer...just check out QUICK SORT in any CompSci text.
As long as you data is in a fairly randomized order...as
the calls come in...Quick Sort will perform very well. It
is the fastest sorting algorithm out there. If the data is
in a fairly sorted manner, then Quick Sort will perform
poorly.
Are you looking to sort the file, then resave it? Open at
a later date, sort, save again? If so, then Quick Sort would not be the method of choice here...perhaps a simple Insertion Sort.
But if the data file will never change, data is simply appended to the end each time, then Quick Sort would be the answer here.
Another thing...you are not going to want to sort solely on the cleint number...since there will be repeats...you need secondary keys (date?) to sort on also for the duplicate cases.
I can post some Quick Sort stuff here if you want...it will not be for your data in particular...but you can easily change it to suit your needs.
As long as you data is in a fairly randomized order...as
the calls come in...Quick Sort will perform very well. It
is the fastest sorting algorithm out there. If the data is
in a fairly sorted manner, then Quick Sort will perform
poorly.
Are you looking to sort the file, then resave it? Open at
a later date, sort, save again? If so, then Quick Sort would not be the method of choice here...perhaps a simple Insertion Sort.
But if the data file will never change, data is simply appended to the end each time, then Quick Sort would be the answer here.
Another thing...you are not going to want to sort solely on the cleint number...since there will be repeats...you need secondary keys (date?) to sort on also for the duplicate cases.
I can post some Quick Sort stuff here if you want...it will not be for your data in particular...but you can easily change it to suit your needs.
The advantage of using a DB is that you can use a reporting tool such as Quick Report or (if you have the RAM and disk space!) Report Smith to create the end of year/month etc reports.
It is also easy to import the data into a spreadsheet such as Excel.
You pays yer money and takes yer choice!
Bryan
It is also easy to import the data into a spreadsheet such as Excel.
You pays yer money and takes yer choice!
Bryan
I wasn't downplaying the DB route here. It is probably the
better choice...perhaps not in terms of speed, since all DBs
have horrible overhead...but in terms of extensibility and
the ability to add functionality in the future, the DB choice
is far easier to implement.
But some folks don't want to delve into DBs, so I figured I'd
five him an alternate choice.
better choice...perhaps not in terms of speed, since all DBs
have horrible overhead...but in terms of extensibility and
the ability to add functionality in the future, the DB choice
is far easier to implement.
But some folks don't want to delve into DBs, so I figured I'd
five him an alternate choice.
With the visual tools in Delphi, DBs are actually rather easy.
I learnt to use them in two or three days.
The only complex idea is of JOINs, and linked tables.
Apart from that conceptual problem, it's all drag and drop!
This case depends on how fast you need a solution,
how experienced you are with code or databases,
and what size you need the project to be.
I don't think the speed issue is a problem here, as it's
a very simple problem. With a larger system, the speed
drop using a DB might become noticable.
I learnt to use them in two or three days.
The only complex idea is of JOINs, and linked tables.
Apart from that conceptual problem, it's all drag and drop!
This case depends on how fast you need a solution,
how experienced you are with code or databases,
and what size you need the project to be.
I don't think the speed issue is a problem here, as it's
a very simple problem. With a larger system, the speed
drop using a DB might become noticable.
Do you think the original question asker is even listening anymore????
Do you want ideas on how to perform a sort on a large set of records? Do you need sorting algorhitms? Any technical problems regarding file read/write/seek?
If it's any of the two first problems, just let me know... If it's something related to implementation, post source...
Regards,
Erik.