Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re: Perl DBI for MariaDB v SQLite in a Single Use SBC

by cavac (Parson)
on Mar 20, 2023 at 07:49 UTC ( [id://11151076]=note: print w/replies, xml ) Need Help??


in reply to Perl DBI for MariaDB v SQLite in a Single Use SBC

Besides the other posts telling you how to import the data into SQLite, what's wrong with running MariaDB (or PostgreSQL, for that matter) on the SBC?

I've had PostgreSQL running on the old Raspberry Pi 3 in conjunction with a webserver. It will need a bit of tuning to run smoothly on limited resources, but modern single board computers are often quite capable. You didn't post the specs of your SBCs, so i can only take a stab in the dark, but it it has at least 512MB Ram and runs Linux, a "grown up" database should run on it when configured correctly.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP

Replies are listed 'Best First'.
Re^2: Perl DBI for MariaDB v SQLite in a Single Use SBC
by marto (Cardinal) on Mar 20, 2023 at 08:52 UTC

    "It will need a bit of tuning to run smoothly on limited resources"

    If SQLite can do the job, why bother? Adding something that's hundreds of megabytes and requires extra effort to run smoothly vs something tiny in comparison that performs well out of the box seems sensible on SBCs.

      That really depends on the OPs requirements. If they already have a working application, changing the database backend (or going farther and make it configurable) can be a huge pain. That starts with simple stuff like timestamp handling between different databases and support for different basic features (foreign keys, typecasting, upper/lowercase conversion functions, unicode handling etc). But even slightly more complex SELECT statements can run into troubles, SQL has many different dialects.

      Also, SQLite doesn't support partitioning, XML and JSON handling (other than "as text") and server side scripting. If an existing application relies on any of that, a major rewrite would be required.

      As for "running smoothly out of the box", SQLite is a bit problematic as well. For one, if your application uses more than a single table, it pretty much has to manually activate correct handling of foreign keys everytime it opens the database:

      PRAGMA foreign_keys = ON;

      This will increase memory requirements and slow things down a bit. But running a database without proper foreign key support is just asking for trouble.

      I'm not saying SQLite is the wrong choice per se, it really depends a lot on the circumstances. If OPs project is a blank slate/green field project that runs a single process SQLite a good choice (i use SQLite for similar stuff). But if it's "porting existing, multi-process/multi-thread software to a different hardware", the situation is a lot more complicated. We don't know the design of OPs software, we don't know how complex and mature it is. But since they plan to hand demo systems out at trade shows (to potential customers, probably?), i have to assume that the demo project has more than "trivial" complexity, has been tested a lot already and it has to work without any major new bugs.

      PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
        It is VERY simple queries, just a lot of them that run over and over again with slight changes to each because it is an error checking program, and there is no limit in the variety on how humans can make mistakes.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11151076]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (3)
As of 2024-03-29 01:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found