4 ms·

> They seem to solve many issues on the surface, but not really in practice I believe you haven't had a chance to work on problems that require an actual datab

by dig1 3y ago

> They seem to solve many issues on the surface, but not really in practice I believe you haven't had a chance to work on problems that require an actual database. Multi-user access, ACID support, unified API (odbc/jdbc), common query language... all of these would require many man-years to set properly with a custom solution. > the update disasters, the incompatibility between different SQL engines etc all make it seem like an awful idea What update disasters? If you meant by updating database versions, these aren't things you do frequently because the database is expected to be running 24/7. But Postgres and Mysql are already rock solid here. Wrt SQL engine incompatibilities, you usually set with a single database vendor in practice. If you suddenly start to switch databases in the middle of the project, something needs to be fixed with the process design, not database.

bun_terminator 3y ago
All these comments seem to fuel my suspicion that we in fact shouldn't use databases, because we don't use any of these features. We just use them as external data storage for a single application. And not even that much data, like <10 gigs. But the updating I would have expected to go more smoothly. If you make a point of using a software dedicated to managing data, I sure as hell would expect an update to go so smooth that I don't have to worry about or even notice it. In reality updates more often than not seem to come with undocumented errors. That is a constant source of frustration for me.
- dig1 3y ago
  > because we don't use any of these features. We just use them as external data storage for a single application. You are using it :) Reboot the server where the database runs or suddenly cut off the connection. Unless you have ACID-compatible storage, you'll have malformed data. Plan for the future and use a database from the start. When your project/company expands and starts to use multiple applications/services (and that inevitably happens), you'll see (one of) the benefits of the database. > But the updating I would have expected to go more smoothly I'm not sure what you are talking about. Database updates are one of the smoothest (critical) software updates you'll find, assuming the database has a good track record.
  - bun_terminator 3y ago
    eh the oracle upgrades went awful. But I try to not touch the database at all if I can
    - jauco 3y ago
      Well, oracle is kind of a beast. If all you need is data storage and maybe an index for fast lookup within 10G of data, sqlite will probably do the trick. It is a library, not a server process so you compile it into your app and there is very little ops work to do. As a benefit, you can do many data access patterns that are closer to what you’d do if you wrote the data access code by hand (no network latency etc)

by dig1 3y ago

bun_terminator 3y ago

All these comments seem to fuel my suspicion that we in fact shouldn't use databases, because we don't use any of these features. We just use them as external data storage for a single application. And not even that much data, like <10 gigs. But the updating I would have expected to go more smoothly. If you make a point of using a software dedicated to managing data, I sure as hell would expect an update to go so smooth that I don't have to worry about or even notice it. In reality updates more often than not seem to come with undocumented errors. That is a constant source of frustration for me.

dig1 3y ago
> because we don't use any of these features. We just use them as external data storage for a single application. You are using it :) Reboot the server where the database runs or suddenly cut off the connection. Unless you have ACID-compatible storage, you'll have malformed data. Plan for the future and use a database from the start. When your project/company expands and starts to use multiple applications/services (and that inevitably happens), you'll see (one of) the benefits of the database. > But the updating I would have expected to go more smoothly I'm not sure what you are talking about. Database updates are one of the smoothest (critical) software updates you'll find, assuming the database has a good track record.
- bun_terminator 3y ago
  eh the oracle upgrades went awful. But I try to not touch the database at all if I can
  - jauco 3y ago
    Well, oracle is kind of a beast. If all you need is data storage and maybe an index for fast lookup within 10G of data, sqlite will probably do the trick. It is a library, not a server process so you compile it into your app and there is very little ops work to do. As a benefit, you can do many data access patterns that are closer to what you’d do if you wrote the data access code by hand (no network latency etc)