>In one case I've got a personel time tracking mechnism. This person has depending on various factors an amount of leave hours in one year. The mechanism has to deal with date_in_service, date_out_of_service, changing roster, sickness, exceptional leave, normal leave, maternaty leave, etc.
>It has to calculate the remaining leave hours for this person.
>
>I could choose for adding an extra field in which the remaining leave hours are stored and recalculate them if something changes in the parameters. But this would probably give performance problems when I change one of the rosters which could apply to numerous persons in various years as I would have to recalcute the extra field. Besides this there is an potential problem that the extra field goes out of sync.
>
>The solution I choose is to calculate the remaining leave (and other data) hours when requested. To maximize performance when the remaining leave hours of large amounts of persons is requested (for e.g. in a report), I've got the whole mechanism tuned for performance and now it takes about 0.03 seconds to calculate the leave hours for one year for one person. I've had to use every trick to save CPU cycles and test various data handling mechanism to accomplish my goal. Within a loop of 366 days each CPU cycle won is important.
>
Walter, this is raw, unadulterated bullshit, or you haven't thought about this for 2 seconds. Probably both. There's no serialization necessary in the process. Take a dozen bullshit systems, partition the data set into isolated domains, and go. Use old bullshit 486 boxes. Use a couple dozen boxes. There's nothing blocking inherent parallelism. I just scaled your app back to run in 1/10th the time with at most a minor code change. And I can throw more iron at it faster than and cheaper than you can creeb cycles. This ain't mission-crticial, real-time event duration sensitive work, Bucko.
Get a clue. Get a life. Get some concept of what you're saying, because if it's cycle-tight, not real-time, and not inherently serial, throw more hardware at it. IRON AND SAND IS CHEAP. FUNCTIONING BRAINCELLS ARE NOT. I worked small scale lab systems with event duration response limits, and have written device drivers. And I've writen things where one box couldn't do the job, so we did, hmmm...could it be...distributed processing?
Walter, I'm not impressed. Like I said, you're bullshitting or stupid - take your pick. I'll assume you're convinced you're smart Walter. Go convince your clients. I have work to do and people with a clue who ask semi-intelligent, rational questions. For a "theory heavy" expert, you just don't know jack. You don't know the terminology. You don't even know the platform.
>>I've seen this in threads with you and JimB, who knows this concept absolutely dead cold to rights. None of this crap you're working on or I'm working on will be measurably improved by spending measurable time creebing code to gain 4 CPU cycles per run. It will be measurably improved, as will the sanity of the next guy picking up the code to MAKE THE CODE CLEAN, CLEAR, MAINTAINABLE AND COMPREHENSIBLE. This is why you and I will never agree on our approaches to how to code. You want to xBASE it up, be smarter than the tool, show off how much you know before it happens. I like SQL - it's concise, it's clear, it's maintainable, and in the event that the data is smarter than I am, letting the data engine find the best path to solving the problem based on its knowledge of the state of the data from experience and heuristics rather than my guessed behavior is going to beat the crap out of my programmatic solve based on faulty assumptions. And when it gets too big for VFP I don't have
>>to rethink the whole problem.
>
>Ed, I don't think you understand my standpoint. I don't exclusively use xBase construct. Whereever SQL will do the job clean and nicely without significant performance decrease I'll choose SQL. I fully agree on your statement that SQL is far more constructive, clean, consise, etc.
>
>However, I've got several cases (like the one described above) where SQL is getting you nowhere and leads to serious performance problems. Especially where performance is very important, I'll look for alternatives like xBase constructs, which can do the job SQL can't.
>
Failed imagination is about the best you're gonna do on this.
>The difference between you and me is that I want the fastest tool for the job and you only want to use SQL even in cases where it is doing a very poor job and refuse to even consider an xBase eqiuvalent.
>
Then why in all of hell do you use VFP? VC++ will blow away VFP for math, and I can spin through files that use indexed access using a ton of faster mechanisms than VFP can put to use. The closest you've gotten to speed might've been some benzedrine you popped in school. If you're really convinced you have a clue, why the frack are you burning cycles interpreting p-code for a living?
>Let's take the following example:
>
>An employee table contains an emp# and a chief#. The chief itself is also an emplyee and also has a chief. The following two examples gets the upper chief of a random employee.
Stop. I dump a relational model and put up an app based on ObjectStore used as a network-model database and use a language platform with an internal concept of list and direction. Case closed. Oooh, no fair - I picked a tool that has a clue about lists and digraphs. I have a clue what a digraph is...
