3 ms·

Postgres was the first relational database I came into contact with, Interbase the second and Oracle the third. Lately I've been writing a REST back end on top

by codr7 4y ago

Postgres was the first relational database I came into contact with, Interbase the second and Oracle the third. Lately I've been writing a REST back end on top of MariaDB at work, and I swear it's going to drive me insane with its arbitrary limitations. At least SQLite offers something in return that Postgres can't do.

5e92cb50239222b 4y ago
> At least SQLite offers something in return that Postgres can't do. If you're going to throw allegations around, at least get your facts straight. MariaDB and MySQL support complex replication topologies out of the box, including multi-master. Yes, it does come in useful if implemented correctly: we built a business application for a particular setup with many branches around the country, many of which have very unreliable network and must be able to continue working with a local database when that network is not available. It has been running for 4-5 years without issues. They're also much easier to support: for example, upgrades are handled automatically — no need to dump and restore or resort to weird tricks; you can easily upgrade through ten major versions just by installing the latest version and restarting the daemon. Some other features off the top of my mind: compression (zlib, lz4, lzo, zstd), versioned tables (an absolute life-saver if you need audit).
- mschuster91 4y ago
  > we built a business application for a particular setup with many branches around the country, many of which have very unreliable network and must be able to continue working with a local database when that network is not available. It has been running for 4-5 years without issues. How do you deal with reconciling after a connection loss? Is your client application read-only / the data sharded in a way that it doesn't matter for other branches if one branch is offline?
TylerE 4y ago
If you think that's bad, you weren't around for the MYiASM (I think it was.. days). Yeah, for years, MySQL shipped with a default storage format that didn't enforce constraints.
- dakna 4y ago
  To be fair,in those days MyISAM was pretty much the only DB engine that could keep up with the traffic growth rates of the early web, because it didn't enforce constraints. It was optimized for reads, not writes, and was fast enough to hold all state in one DB server for heavy traffic sites. Combined with stateless PHP and memory caching it was the best tool to use for this use case. That it wasn't the best engine for all use cases and also corrupted data on disk occasionally is a different story. Once InnoDb was ready, you could just mix and match engines in one DB server as far as I remember and use referential constraints where needed. Later MongoDB marketed itself as "web scale" due to no schema constraints at all. Fun times.

by codr7 4y ago

5e92cb50239222b 4y ago

> At least SQLite offers something in return that Postgres can't do. If you're going to throw allegations around, at least get your facts straight. MariaDB and MySQL support complex replication topologies out of the box, including multi-master. Yes, it does come in useful if implemented correctly: we built a business application for a particular setup with many branches around the country, many of which have very unreliable network and must be able to continue working with a local database when that network is not available. It has been running for 4-5 years without issues. They're also much easier to support: for example, upgrades are handled automatically — no need to dump and restore or resort to weird tricks; you can easily upgrade through ten major versions just by installing the latest version and restarting the daemon. Some other features off the top of my mind: compression (zlib, lz4, lzo, zstd), versioned tables (an absolute life-saver if you need audit).

mschuster91 4y ago
> we built a business application for a particular setup with many branches around the country, many of which have very unreliable network and must be able to continue working with a local database when that network is not available. It has been running for 4-5 years without issues. How do you deal with reconciling after a connection loss? Is your client application read-only / the data sharded in a way that it doesn't matter for other branches if one branch is offline?

TylerE 4y ago

If you think that's bad, you weren't around for the MYiASM (I think it was.. days). Yeah, for years, MySQL shipped with a default storage format that didn't enforce constraints.

dakna 4y ago
To be fair,in those days MyISAM was pretty much the only DB engine that could keep up with the traffic growth rates of the early web, because it didn't enforce constraints. It was optimized for reads, not writes, and was fast enough to hold all state in one DB server for heavy traffic sites. Combined with stateless PHP and memory caching it was the best tool to use for this use case. That it wasn't the best engine for all use cases and also corrupted data on disk occasionally is a different story. Once InnoDb was ready, you could just mix and match engines in one DB server as far as I remember and use referential constraints where needed. Later MongoDB marketed itself as "web scale" due to no schema constraints at all. Fun times.