Re: teaching a child - console or GUI

From: Bjørge Sæther (bjorge_at_hahaha_itte.no)
Date: 07/29/04 

Date: Thu, 29 Jul 2004 01:26:11 +0200

not@any.adr wrote:
> On Wed, 28 Jul 2004 14:33:28 +0200, "Bjørge Sæther"
> <bjorge@hahaha_itte.no> wrote:
>
>> While I do follow your reasons for not wanting to use one ready
>> built, there is a paradox:
>> The more nifty features you put into your "database" engine, the more
>> reasons there is to use a standard RDBMS. ;-)
>
> I see your point... but I've always adhered to a principle my father
> always yelled about "KISS" (Keep It Simple, Silly) I don't generally
> do "nifty features" in these systems for the simple reason that with
> many of my customers (who know less about computers than I do about
> brain surgery) extra features just means more screw ups.
>
> I provide a solid minimal feature set and things go along nicely.

When dealing with end users that are not technicans - definately. Whatever
solution that doesn't fail, and preferrably - that doesn't require them to
learn a term like 'database server'. I've been maintaining an application
written back in '95 based on Paradox, now I'm asked to do a new version.
I'll go for flat files, as this will remove a "magic box" from the users'
universe - the demanding and unpredictable database. I'm quite proud of the
"build / rebuild database" - function and the advanced backup system...but
one file per "logical unit" (it actually resembles a kind of document) would
solve it all with no work at all. If I used XML format, I'd also be *very*
trendy ;-)

> Application wise, each terminal has it's own local software and OS,
> is fully capable of running without the server online... the only
> thing it can't do without the server is update inventory or transmit
> reports. In this case the data goes into a couple of local
> sequential files which are batch processed when the server comes back
> online.

That's maybe a good argument for not using an RDBMS - you rarely need more
than a small portion of it. Another argument: "Modifications". The
Paradox-based app I mentioned has a built-in functionality that would
restructure an existing database whenever there are changes made to the
system. That is *not* standard Paradox, but having 50+ users scattered
around the country means that this functionality would soon pay off. Another
thing was a fool-proof setup system that would not be able to erase anything
whatsoever, at that point WinZip was kind of an ideal to me (just download
an exe-file and run it).

>> If you haven't experienced maximum performance of a modern RDBMS
>> system, I'd advice you to get someone show you.
>
> Ok... my biggest system so far (14 terminals in a food store) handles
> at most about 250 transactions per minute, more like 50 per minute on
> average, a 386 could keep up to that.

14 persons hammering their keyboards or using barcode automats won't be able
to produce a tremendeous load, I can believe that. 14 clerks booking the
same flight- or concert tickets, otoh, would be another story ;-).

> In the more intense corporate environments (which, so far, I've
> avoided) your suggestions make perfect sense... but in my customer
> base it would be sort of like fishing with dynamite.

Have you ever compared the effectiveness of dynamite with, say, fly fishing
?
;-)

> To give you an idea how minimal it is, this is a typical inventory
> record used with my systems...
>
> InvItem = record
> Barcode : int64; // package barcode
> Price : longword; // price in pennies
> Deptment : word; // department number
> QPPack : word; // quantity in each package
> InStock : word; // number in stock
> MaxStock : word; // nominal stock level
> MinStock : word; // reorder if less than
> OnOrder : word; // how many on order
> Cost : longword; // cost price in pennies
> Descript : string[80]; // item description for display
> end;

What if the customer has more than 65535 items in stock ?
What do you do when a Price exceeds 41 millions ?

...it is evident that your system will soon collapse....;-)

> I've had customers ask why I don't use the more comprehensive data
> base setups and once we analyse their needs, for the most part they
> end up realizing they don't need a tenth of what those systems can
> do. Most just need a re-order system and daily totals... Only one
> store does any kind of financial forecasting that I know of and, as I
> mentioned above, about half of them still do manual accounting.

You could offer them an Oracle-based version...still using your files but
collecting a fair retailer's fee from the idling Oracle engine. Then offer a
maintenance deal offering a guaranteed 30 minutes response time whenever the
system stops. ££££, you know ;-)

> (Oh the joys of taking on the small jobs nobody else wants [smile])

That's where the good deals are ;-) 

-- 
Regards,
Bjørge Sæther
bjorge@haha_itte.no
-------------------------------------
I'll not spend any money on American Software products
until armed forces are out of Iraq.

Relevant Pages

  • Re: Transaction processing advice
    ... screen on my server where the data are entered into the database. ... handles sending the emails to the customer and the seller. ... Sometimes it is worthwhile to wait a few seconds and retry the connection ...
    (comp.lang.php)
  • Re: performance in a large table
    ... true source of the problem is not that difficult these days. ... Server load but that doesn't mean you can't fix that. ... Our biggest customer has a 1.1 TB database and they are not ...
    (microsoft.public.sqlserver.clustering)
  • Re: A Quality Penetration Test
    ... I've once worked for a VAR that sold vulnerability scanning/discovery ... Advanced External Penetration Test that our team delivered to a customer. ... to use those unchecked variables to penetrate into our Customer's Web Server ... automatically dump the contents of the database when executed. ...
    (Pen-Test)
  • Re: performance in a large table
    ... Determining if the SAN is the bottleneck and the true source of the problem is not that difficult these days. ... Most SAN's are not properly configured for a high end SQL Server load but that doesn't mean you can't fix that. ... It really sounds to me like the database code or schema is simply not optimized for such a large db and that needs to be addressed first. ... Our biggest customer has a 1.1 TB database and they are not ...
    (microsoft.public.sqlserver.clustering)
  • Re: Reading directory from OSBC settings
    ... Paradox and dBase are 'File based' databases, ... database files is vital for the application to work. ... there is a separate Server process running on the Server ... physical path to the DB files any more. ...
    (comp.lang.pascal.delphi.databases)