Re: Article about supposed "murky" future for Oracle

"Mark C. Stock" <mcstockX_at_Xenquery .com> wrote in message news:<4-6dnc53GKJ-7e3dRVn-tA_at_comcast.com>...
> "Niall Litchfield" <niall.litchfield_at_dial.pipex.com> wrote in message
> news:40705b73$0$247$cc9e4d1f_at_news.dial.pipex.com...
>
> |
> | >
> | > how many users know how complex the underlying query is -- and why
> should
> | > they care? they DO know their data (or else they are in more trouble
> than
> a
> | > database can solve for them) and they have a right, and we have an
> ethical
> | > duty, to present it to them honestly. it is OUR job to ensure that the
> | > output from our systems is 'actually correct'
> |
> | Often as not people *don't* know the data. Ask questions like "how many
> | people does the business employ? How many of those are managers?" In any
> | reasonably sized business the chances are even the HR director won't be
> able
> | to tell you without one or more reports, and they will not guarantee the
> | exactness of the reports, becuase of data entry error etc. In your
> projects
> | ask the project manager for an estimate of what the spend or hours worked
> to
> | date has been, then compare to the recorded figures.
> |
>
> granted, that is too often the case (did i get a bit hyperbolic to make a
> point?)
>
> by contrast, however, i've had quite a few experiences with end-users saying
> things like "that just doesn't look right" and "i know that's not true". how
> much of that would be affected by the types of transaction-agnostic
> inconsistencies this thread has been discussing is up for debate, but the
> most likely scenario were inconsistent database reads affect data integrity
> is in cases where reports must be consistent within themselves, or the exact
> time of the report is of significance, or other transactions are spawned
> based on the dirty reads (ie, not all database reporting is for human
> consumption)

I'm going through that yet again as I implement an MRP type report that replaces a manually updated spreadsheet. Disagreements between the spreadsheet and report are inevitably human error, but disagreements between the report and what people "know" tend to be bugs (or design miscommunication), because the people know their data and how it is supposed to work, whether or not they can verbalize it - the last is the analyst's job, of course.

>
> and yes there are data entry errors, which is why we design systems to
> validate the reasonableness of data as well as audit data changes, and
> otherwise reduce the potential for human error

Which is the basic problem with spreadsheets (except perhaps those that are automatically loaded from clean databases.)

>
> and you're right, users will not be as intimately familiar with data they
> 'own' but that are not the central focus of their job responsibility (your
> pm hours example) -- but many have aspects of the data that they understand
> far better than anyone else in the organization
>
> perhaps your figures on inaccurate and not well-understood corporate data
> reflect an industry tradition of 'good enough - ship it'? -- of course,
> present company excluded ;-)
> perhaps that industry tradition contributes to the acceptance of
> technologies and techniques that find fuzzy data acceptable, without
> admitting that the results are actually not actual (or would that be not
> actually actual?)

I think the figures indicate the error a bunch of managers entering data into spreadsheet cells introduce :-O

Set one extra credit into a GL month-end run and see how fast people notice and scream.

>
> ;-{ mcs

jg

--
@home.com is bogus.
http://www.maledicta.org/