Approaching Omnis again scares me, too much to learn?

[Clifford Ilkay]

On Thu, Jan 4, 2018 at 12:02 PM, Doug Easterbrook <doug at artsman.com> wrote:

> just for the record.
>
> sqllite is NOT a great replacement to the native data file.   This is one
> web page that gives a brief summary of
>
> the biggest limitation of mysql is ’NO MULTI USER’.    so, if you ever
> think your app might be used by two people..   that design decision kills
> your future even thinking about sqllite.    its also not that fast - I
> spent a month trying to use it locally to save bunches of data for caching
> — truly ..  very slow for large amounts of data.



I second this. In all the years I've been using SQL databases, the only use
case I've found for SQLite that made any sense was in the Django
configuration application I built to store key/value pairs that are
eventually used by SaltStack to configure the virtual machine in which the
configuration application is running. That application will never be used
by more than one user at a time. In fact, I could have gotten away without
storing that data in a database and just a YAML file, which I also do, but
storing in a database gives me the ability to ensure the configuration
record is a singleton. We used to have PostgreSQL within that virtual
machine for the main application but when that use became deprecated after
it was replaced by PouchDB, I didn't see the point of having an industrial
strength database just to store one record that could ever be created,
read, or updated by one user. Switching from PostgreSQL to SQLite in the
Django application was as simple as changing the database connection string.

This leads me to the question of whether it's even necessary for someone to
learn SQL today. For most use cases, I'd argue that writing raw SQL is a
waste of time. It's not that it's so complex. It's that using an ORM
(Object Relational Mapper), like the Django ORM, abstracts out the
underlying database. That has a couple of advantages. First, if you need to
switch between database, like I just did going from PostgreSQL to SQLite,
it will usually be just a database connection change. There won't be any
changes necessary to the query code. Second, the way you interact with the
database is more natural. Django is written in Python so the Django ORM
treats records as objects and works out the underlying details. It's
mature, it's fast, and it's easy to understand. With an ORM, I don't need
to have two different mental models and languages. My queries can be
expressed as natural Python and the result set can be treated like an
object. ORMs are not limited to Django, of course. The only time I had to
write raw SQL with the Django ORM was to work around MySQL's buggy query
parser when working with billion row tables. For the vast majority of
cases, you'll never need to do that.

Regards,

Clifford Ilkay

+1 647-778-8696