Re: dBase

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: trent shipley via PLUG-discuss
Date:  
To: Main PLUG discussion list
CC: trent shipley
Subject: Re: dBase
It looks like SQLite was meant to be a modest application's dedicated SQL
enabled data store. It was never meant to be concurrent, multiuser or
intensely transactional. A database professional would say that's a
stupidly lazy programmer trick.

On a similar note I've been reading software engineering books which say
letting the data architects engineer the database is a bad idea, just let
the programmers evolve the disperate databases and stores as they use agile
methodology to evolve the enterprise systems -- I think of the poor
accountants and data scientists, and think "why am I listening to a
software engineer tell me how to architect the data on the premise
organizing the data is a lost cause anyway which only slows the
enterprise's agile?"

On Thu, Dec 29, 2022, 20:20 George Toft via PLUG-discuss <
> wrote:

> I made a mistake in an application by using SQLite3. I read about
> SQLite's advantages over MySQL in that it has no network stack, so it's
> faster. My testing showed that was kinda true - it was faster mostly,
> until multiple tasks started accessing the database concurrently. I
> applied some fixes I found on the Internet and that helped, then I got
> clever and wrote a wrapper to prevent contention over the database. I
> tested with 60 concurrent requests and it worked fine. The code made
> its way into production. A couple weeks later, in a perfect storm of
> slash-dotting, we got hit with triple the load we ever experienced. One
> of the storms was the cron job that updated a record in the database.
> The field update failed and all of the other processes relying on that
> field failed. This was the only outage my team suffered in 2021. I
> switched over to MySQL (MariaDB) and never looked back. Haven't had a
> self-induced outage in over a year.
>
> And then one of our vendors uses SQLite to store client information
> (client as in client-server) in the licensing server, and guess what -
> we figured out how to break it without even trying. I actually had the
> opportunity to have some 1:1 time with the product manager, and I was
> letting him know how his licensing scheme was a huge risk and a single
> point of failure. About that time, the CIO of a South African bank
> comes up and chimes in about what a piece of crap the licensing system
> was, major single point of failure. Product manager just turned his
> back and walked away. Meanwhile, I took the lesson from the CIO and had
> my team apply it to our infrastructure after our 3rd database crash. No
> license server, no functionality. Fortunately, it was still in
> development and didn't impact anyone.
>
> I am not a fan of SQLite. Sure, put it in an embedded device, but not
> anything connected to a network.
>
> Regards,
>
> George Toft
>
> On 12/28/2022 9:45 AM, Steve Litt via PLUG-discuss wrote:
> > Keith Smith via PLUG-discuss said on Tue, 27 Dec 2022 19:02:42 -0700
> >
> >> SQLite surly looks cool, however I would not call is a replacement for
> >> dBase III. dBase III was very structured and provide the ability to
> >> create forms with widgets.
> > IIRC dBase could make only CLI forms, not GUI forms. If one is willing
> > to restrict one's self to CLI on an 80x25 screen, it's trivial in any
> > language to create functions say() and get(). This is even easier today
> > because you can represent the screen as a 25x80 2 dimensional array,
> > rather than having to construct it from the top down the way you did
> > when 20K was unaffordable.
> >
> >> It looks like SQLite would require some programming and the use of
> >> ncurses or Qt... or maybe some other screen building language. Am I
> >> wrong?
> > It would be more professional to use nCurses, but you can use plain old
> > screen writes if you wanted to. As far as Qt, my understanding is
> > that dBase never could do proportional spacing or different fonts.
> >
> >> Still it is pretty cool!!
> >> Microsoft owns Visual FoxPro ... why not trim that down?
> > No need to rely on Microsoft. Harbour Project is a Free Software
> > Clipper almost-workalike. https://harbour.github.io/
> >
> >> MS also owns MS-Access which is a kludge in my opinion.
> > Access was a nice DB design tool, but I wouldn't trust it to hold my
> > data.
> >
> > SteveT
> >
> > Steve Litt
> > Autumn 2022 featured book: Thriving in Tough Times
> > http://www.troubleshooters.com/bookstore/thrive.htm
> > ---------------------------------------------------
> > PLUG-discuss mailing list:
> > To subscribe, unsubscribe, or to change your mail settings:
> > https://lists.phxlinux.org/mailman/listinfo/plug-discuss
> ---------------------------------------------------
> PLUG-discuss mailing list:
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>

---------------------------------------------------
PLUG-discuss mailing list:
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss