Have you considered using the Tap Forms app on your Mac?
Tap Forms on the Mac App Store
EDIT TO ADD: Tap Forms is a full-featured front end to an SQLite database file.
Have you considered using the Tap Forms app on your Mac?
Tap Forms on the Mac App Store
EDIT TO ADD: Tap Forms is a full-featured front end to an SQLite database file.
I have got Tapforms, but kept hitting problems and limitations. I might give it another look, but will still learn SQL.
The core development team moved away from mySQL when it was acquired by Oracle. MySQL was forked as MariaDB. MariaDB is fully compatible to mySQL but in the FOSS community it is considered the better choice (licensing, commercialization by Oracle,…). MariaDB is also faster than mySQL. In fact, often enoug, when you read mySQL it’s really MariaDB under the hood (Wikipedia). And many Linux distributions moved from mySQL to MariaDB as the default database (Debian, Fedora, CentOS,…).
If Tap Forms does not work for you then by all means try something else. But SQLite works at a much lower level than does Tap Forms. That is, Tap Forms does more for you whereas with SQLite, more has to be done by you.
Yea, I know. Details. Simply add it to the list of SQL Servers. Actually I have MariaDB running on my Mac and Synology NAS so I do know about it. Habit to say “MySQL”.
… implementation details … and politics …
I am also guilty of saying “mySQL” 3/4 of the time. And doing a terrible disservice to the development team. I think Google also moved from mySQL to MariaDB a decade ago. So it should be better known.
Personally, I prefer PostgreSQL.
I spend most my effort on the querying and data analysis side of databases. Sort of agnostic about the server or if SQLite.
The terms for this topic are badly overloaded and intermingled. I find this set of definitions helpful:
Relational database management system (RDBMS): Software that’s used to store data that’s organized in structures called relations (or tables). Examples include Oracle, MySQL, SQLServer, PostgreSQL, SQLite.
Structured Query Language (SQL): The “standard” language used to define the structure of, manipulate, and query data in an RDBMS. Each RDBMS has its own variation of SQL that depends on the features supported, but SQL itself is highly portable and learning it for one system means you’ll know the basics for any other.
Database: An abstract collection of data that makes sense to store in a single repository.
Database: A collection of files that contain the data managed by an RDBMS.
Database: Some combination of any or all of the above.
It does not help that most RDBMS(s) have SQL in their names.
For most stuff it doesn’t matter at all. Our productive database is Oracle (no choice there), for data analysis we use MariaDB, I like PostgreSQL because of PostGIS.
My impression has always been that if you’re talking about super-complex queries or high-concurrency multi-user systems one of the “fancy” RDBMS systems (mySQL, MariaDB, etc.) is the way to fly. But for most little projects or anything that’s basically a single instance on a single device, SQLite is fine.
Thoughts?
The real valuable and important stuff about databases is what’s not been discussed here, but suggested by a few. I’ll leave it at that.
Bento, gone too soon, we hardly knew ye
Yep, I would agree with that.
RDBMS have been the backbone of transaction heavy industries forever. Banks were among early adopters, as the database engines would ensure things like referential integrity, allow for two-phase commits that made sure deposits, withdrawals and charges would be done once and ONLY once and lots of other high end features that are rarely needed in personal use.
SQL was initially developed at IBM by Donald D. Chamberlin and Raymond F. Boyce after learning about the relational model from Edgar F. Codd[12] in the early 1970s.
Despite this, Oracle managed to beat IBM to market by releasing the first commercially available version. IBMs db2 were released a few months later.
Another feature is the practice of “normalizing” your data model by using multiple tables, allowing for things like keeping customer data separate from account data, simply joining the two with a common key.
Agree.
The thread was started with the question “what’s the best database”. Without any further information, use case or requirements. So, of course we jumped on that and threw mySQL/MariaDB/PostreSQL into the discussion.
The “Lite” in SQLite might be misleading. Ten thousands of albums, by thousands of artists, with hundreds of labels, …no problem at all.
SQLite/SQL is a great way to store data, since you will always be able to access/export it. In the dark ages, I was forced to create some stuff with MS Access (Version 2?). Completely closed. Getting the data out of there is a full-time job (if it still exists at my pastpastpastpastpastpast employer).
This is correct. I teach a bootcamp that covers all the basics and most advanced parts of SQL (excluding complex joins) in 6 hours.
I use MAMP (and XAMPP on Windows) to give access to a fully configured SQL server with PHPMyAdmin for my students. It’s an excellent environment for learning and it’s a cinch to set up - just a few clicks. The free version is more than sufficient. You can start using the web interface to administer the database and see the SQL that’s generated. Then, you can type and play around with SQL commands. In a day you can easily learn everything you need.
You make an important point. SQLite on the Mac is for a single user only.
BTDT just had another issue. I may have to ditch my animal_table design. I’ve realized that by knowing the breed and sex it is possible to get the species but that it might make my future queries MUCH simpler if I just include a field for species now.
Still ruminating (I am after all a shepherdess )
But I’m leaning that way.
This has been what I’ve been told. No experience. I’ve yet to run off the end of SQLite for single user systems.
The key the whole key and nothing but the key, in Codd we trust.