Preferred database

Which database do you prefer to work with if you have the choice?


  • Total voters
    51
A few years ago, someone decided to donate the original source code of "System R" to the Computer History Museum. For those who don't know what this is: The first relational database, a research prototype built by IBM in the late 70s: after Ted Codd invented the "Relational Calculus", a group around Don Chamberlin built an actual system around it, with SQL as the query language. The connection between IBM Research and the Museum was my manager. He started looking for someone who could read the ancient MVS-format backup tape, and it so happened that I had ancient software (from the late 80s) which ran on Unix and decoded the MVS backup tapes (which included converting EBCDIC to ASCII, which is not possible while preserving PL/S syntax). So I got to turn the backup tape turned into a tar file. I have no idea how one can get to the source today.
 
A few years ago, someone decided to donate the original source code of "System R" to the Computer History Museum. For those who don't know what this is: The first relational database, a research prototype built by IBM in the late 70s: after Ted Codd invented the "Relational Calculus", a group around Don Chamberlin built an actual system around it, with SQL as the query language. The connection between IBM Research and the Museum was my manager. He started looking for someone who could read the ancient MVS-format backup tape, and it so happened that I had ancient software (from the late 80s) which ran on Unix and decoded the MVS backup tapes (which included converting EBCDIC to ASCII, which is not possible while preserving PL/S syntax). So I got to turn the backup tape turned into a tar file. I have no idea how one can get to the source today.
Seriously??? Holy shit. If someone is motivated enough, and is capable of connecting the dots, this post contains a truckload of info to get started! For starters, tar is tAR, which is short for tape ARchive... If you succeeded in extracting a tarball from the tape, then just use /bin/untar to do the rest! The original tape is probably over at Computer History Museum, and if you contact them, they just might have the source code available for download as ACII text files. Not only that, there's probably tarballs on the Internet, and Google (with physical headquarters just a couple miles away) will help you find it! :p
1626445647163.png
 
Sorry, I didn't make myself clear. The original tape (from the late 70s) contained an MVS backup, not a tar file. The original tape was read by a volunteer at the museum using a specialized (modified) tape drive. I don't know where the original tape is now. The result of the binary read of the tape was then sent to me. I decoded the MVS backup format, converted the files from EBCDIC to ASCII, and stored them in a tar file. I know that the tar file is in the archives of the museum. What I mean by "I have no idea how one can" is: I did not keep a copy of the files (as they are not owned by me), and I don't know whether they are available on the public internet. And yes, I'm very familiar with the area on that map: Last week, I had a beer with friends at the "Sports Page" bar, which is in the middle of that map.
 
Sorry, I didn't make myself clear. The original tape (from the late 70s) contained an MVS backup, not a tar file. The original tape was read by a volunteer at the museum using a specialized (modified) tape drive. I don't know where the original tape is now. The result of the binary read of the tape was then sent to me. I decoded the MVS backup format, converted the files from EBCDIC to ASCII, and stored them in a tar file. I know that the tar file is in the archives of the museum. What I mean by "I have no idea how one can" is: I did not keep a copy of the files (as they are not owned by me), and I don't know whether they are available on the public internet. And yes, I'm very familiar with the area on that map: Last week, I had a beer with friends at the "Sports Page" bar, which is in the middle of that map.
So, at this point, it's up to the museum to publish that code, since they've assumed stewardship of it. But I would not be surprised if a copy turns up somewhere on public Internet.
 
I've been using databases/percona57-server for a while and it seems to be slightly faster than the same versions of MySQL or MariaDB. Percona Server 8.0 is has been out for a while but not in the ports tree.
Never heard of it until today... even though it's been in ports ever since AMD introduced Ryzen (2017). One sore point for me - some components have never been renamed. Like InnoDB... and the mysql substring is still present in a lot of places - both Percona and MariaDB devs never bothered to completely hunt down and replace that string in the source code. Sure, there's concerns about breaking some of the API's if you do that blindly. I'm sorry, that's just me being an insufferable skeptic today.
 
dBase. Well, in the guise of Harbour Compiler which is a superset of Clipper 5.2. Open source, easy, extensible, flexible. What's not to like? Try it, you never know, you might like it.
Seriously??? that was in use at a small shop where I used to work fresh out of college. It was woefully inadequate even back in 2005, even for a small shop. It was a constant headache fixing broken table files from backup. Yeah, not that hard to figure out the correct fix, because it was Open Source, but broke way too often. I'm still shaking my head at why anyone puts up with that, especially when any RDBMS worth its salt can be accessed from any old ncurses-based front-end.
 
dBase. Well, in the guise of Harbour Compiler which is a superset of Clipper 5.2. Open source, easy, extensible, flexible. What's not to like? Try it, you never know, you might like it.
Ashton-Tate Dbase? That takes me back...
 
Tested PostgreSQL and MySQL fairly extensively a few years ago, using application software written in PHP. Their syntaxes are different, and particularly so where php interfaces are concerned, so I wrote my own php functions and interfaces to allow them to be used interchangeably. This made it fairly easy to compare their performance, and PostgreSQL outperformed MySQL by a significant margin in terms of speed, and seemed more efficient, reliable, and trouble-free in terms of overall administration.

In 2009-2010, Oracle bought ownership of Sun Microsystems, who, by that time, had themselves already acquired ownership of MySQL. Around that same time, the original open-source provider of MySQL cloned his MySQL implementation off as MariaDB. I never got around to trying out MariaDB, but, instead, eventually stopped using MySQL, which was becoming, in my opinion, more trouble than it was worth. Haven't touched MySQL since.
If you haven't used MySQL since 2010, and never used MariaDB, then you have missed out on quite a lot. The prevalent opinion around that time was that MySQL/MariaDB was better for performance, and that PostgreSQL was better in terms of SQL features.

I had forgotten Oracle bought MySQL 🙁 They also bought VirtualBox. Not to get off track but remember when VirtualBox was written by an actual company named "InnoTek" which I think was the same as in the movie "Office Space". Sometimes when big companies buy things they get better, other times not.
In the case of MySQL, I think Oracle's takeover has been a good thing, but I'm not sure it would have been so benevolent without MariaDB providing all that healthy competition.
Never heard of it until today... even though it's been in ports ever since AMD introduced Ryzen (2017). One sore point for me - some components have never been renamed. Like InnoDB... and the mysql substring is still present in a lot of places - both Percona and MariaDB devs never bothered to completely hunt down and replace that string in the source code. Sure, there's concerns about breaking some of the API's if you do that blindly. I'm sorry, that's just me being an insufferable skeptic today.
I think leaving the "mysql" in there has been a deliberate decision. Percona, or rather 'Percona Server for MySQL' which is the full name (they also have Percona Server for MongoDB etc), is really still MySQL with a number of patches, so I think for them it makes sense to leave the mysql string as is. MariaDB on the other hand is a proper fork, and they have now actually renamed it, so the binaries are now actually called 'mariadb' instead of 'mysql' for the CLI client, and 'mariadbd' for the 'mysqld' server, and so on. But for compatibility reasons they have symbolic links called mysql, mysqld and so on.

My personal preference is MariaDB, because that is what I know the best. I prefer it over MySQL because MariaDB development happens more in the open and better follows the open-source model - compare e.g. MariaDB's Jira to MySQL's bug reporting system. Also, I have major issues with the new release model in MySQL 8.0 where entirely new features are introduced in micro/bugfix/patch releases since this will inevitably also introduce new bugs. Also, downgrading is now no longer officially supported. So if you upgrade to the latest version and run into some sort of show-stopper bug, then you're screwed.

MariaDB thankfully supports downgrading and follows the standard release model where bugfix releases are just that - bugfix releases. So it's a fair assumption that version 10.6.4 is more mature and stable than version 10.6.3.

PostgreSQL is second to none in terms of implementing features from the SQL Standard, and they seem to have improved in other areas including performance. It really is a great great DBMS. The only thing I dislike about it is the condescending attitude of some of its proponents.
 
When I have a choice, I prefer to develop greenfield products using CouchDB, a nosql database as the main application database. This makes development much faster and provides great performance in production.

Then, whenever analytics and/or arbitrary queries are needed (for example for business analysis) , I pair it with a SQL database and I use postgres in this case.
 
At best? none.

If I absolutely have to and the software offers it, sets it up and handles everything: SQLite3

If it needs to be a fully fledged database and I have a choice (but SQLite is none of it): PostgreSQL


I don't like databases.
Databases don't like me.
So generally I try to stay away from them if possible...
 
I recently found out postgresql includes a document database with all the features of mongodb

There are major differences though:

- Upgrading postgresql is a pain (you basically can't upgrade: you need to export and import your data)
- The high-availability and horizontal scalability features of MongoDB do not have equivalents on postgres
- throughput can be scaled more easily with MongoDB
- The query planner of postgresql is obscure and hard to debug, query planning is much more predictable on mongodb
- Recently, mongodb has added support for GeoJSON, timeseries, and they have said to also have column-oriented analytical features coming later this year.

I used to avoid MongoDB like the plague because of all the horror stories I've heard about it but I have to say they've come a long way. That being said, more than a love for MongoDB, I wanted to point these aspects because people often leave them out when they discuss PostgreSQL. For example I remember how shocked I was when I discovered that postgresql offered no upgrade path and very few people talk about that. This plus the lack of a decent horizontal scalability make it a no-go for a wide range of mission critical operational databases. Ease of management matters.

For operational databases, NoSQL solutions such as MongoDB tend to be a massive productivity booster. However for reporting and advanced analytical usage SQL can be the best choice. That being said, I do run postgresql and mysql but this is mainly because of non-critical third party tools requiring these databases.
 
PostgreSQL can be upgraded across major versions via replication.
Thank you for pointing this out, last time I checked there was a gotcha related to the fact that not every database object was replicated. Maybe this was related to logical replication vs streaming replication.

Still the upgrade story is too risky for my taste, upgrade in place is a must for a database in my opinion. Otherwise there is too much risk of making mistakes, and every upgrade is a dauting process people will postpone for as long as possible.
 
A reason they did replica upgrades is that you have two copies, instead of one that may go bad during an upgrade and you restore from backup. Can verify live and kill the replica if bad or drop the old one if it's good.

Also, learning to do replication is the horizontal scaling you're talking about!
 
a successor of MDBS (some documents of old MDBS are here - http://www.bitsavers.org/pdf/microDatabaseSystems/)

(in Obi-Wan Kenobi voice) Now that's a name I haven't heard in a long time.

I was using cp/m based micros in the late 70s and early 80s. And one of the amazing things is that in addition to normal software (like Fortran and Cobol compilers, from Microsoft, and a spreadsheet called Visicalc), there was a full-blown database called MDBS III. In a 64K address space! I kept trying to get a copy of it, and never managed.
 
what's the difference?
I'm not much of a DB guy but it could be to do with storage engines?
For example MySQL is the DBMS, whereas InnoDB is an example of the DB.
Likewise Oracle's BerkelyDB is the DB whereas SQLite3 can be used as its "DBMS" (more of a frontend API) since 11g R2.

This may be heresy to say to an actual DBA but I feel that for 99% of use-cases these days, on such powerful machines, SQLite is probably enough ;)
I.e back in the day, running a forums on an embedded DB would not be ideal but now it is possibly quite feasible. Or I am just exposing my lack of knowledge here XD
 
Back
Top