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