121–130 of 137 posts
Databases shouldn't be exciting. They should just work . The main reason webcrap works is because the databases underneath work. If the Javascript crowd had to manage data storage, nothing persistent would work reliably.
> Databases shouldn't be exciting. They should just work . With enough experience with the alternative, things that just work are exciting.
Earlier quoted context omitted.
Typical bitter backend developer spew. Works with Java or C# and hasn't explored much more than OO and procedural. Threatened by anything new, creative or explorative. Stuck in his ways and prefers to do mundane, uncreative and repetetive tasks, like writing boilerplate to get stuff in and out of a database. Soon to be automated away by serverless.
Typical frontend developer spew. Works with JavaScript or Emscripten, hasn't dealt with data integrity, scale, or security challenges. Threatened by people who build things from scratch. Stuck writing handlers, never to see the whole architecture. Soon to be replaced by GPT-3. Thank you, this has been entertaining.
Earlier quoted context omitted.
> I've even seen a few cases where people had data loss which had either gone unnoticed Maybe under MyISAM, but InnoDB has been the default storage engine since 2010.
Under InnoDB, because we’re not talking about file corruption but cases where MySQL would silently and irreversibly discard data rather than throwing an error. For example, inserting a value which is too large for the target data type - it truncates the value so that value is lost unless you have another copy or way to reconstruct it.
I commented in another thread about this. It's not black or white whether that's a bug or a feature since:
1) not truncating causes the whole row to be rejected in Postgres, or with the relevant MySQL server setting
2) for many SaaS and social media apps, truncating that column type is fine, since typically that's a description field
3) auto-truncation means you don't have to sync your app and database schema after every change.
I prefer and rely on MySQL's behavior actually, even though I work with both MySQL and Postgres.
Source: DBA.
Earlier quoted context omitted.
I’m not being edgy you took a data format and pretended it was a refutation when it wasn’t and isn’t.
What does the JS in JSON stand for? Where did it come from?
Earlier quoted context omitted.
What does the JS in JSON stand for? Where did it come from?
What does that have to do with JSON being an intermediary language and not the actual persistence part? What part of that don’t you understand and I’ll try to explain it for you
Earlier quoted context omitted.
> I'd rather have my database complain than do stuff that could lose data. One great example is when you try to stuff more characters into a text field than it can accommodate. By default, MySQL just truncates the string silently; Postgres just doesn't allow it. That's your opinion, but the truth is not necessarily black and white. Postgres will probably lose more data in your case when the application developer does…
Here's the deal: I am not presenting my opinion as objective fact, nor do I actually care that you're a DBA. If anything, the fact that you are a DBA makes your opinion less relevant to me as an application developer. Simply put, you do not share my pain, and the people who have upvoted me, while your comment is currently gray as I write this, have. The example was intended to show a scenario in which MySQL silently…
So you're dogmatic and can't accept alternate opinions. And you'll continue whining while the world runs on MySQL, including trillion-dollar companies like Google and Facebook, not Postgres. Got it - what a tool.
Earlier quoted context omitted.
Here's the deal: I am not presenting my opinion as objective fact, nor do I actually care that you're a DBA. If anything, the fact that you are a DBA makes your opinion less relevant to me as an application developer. Simply put, you do not share my pain, and the people who have upvoted me, while your comment is currently gray as I write this, have. The example was intended to show a scenario in which MySQL silently…
> The example was intended to show a scenario in which MySQL silently loses data. So you're dogmatic and can't accept alternate opinions. And you'll continue whining while the world runs on MySQL, including trillion-dollar companies like Google and Facebook, not Postgres. Got it - what a tool.
Edit: I notice a lot of gray on your profile page under comments. Do you need help? This is a genuine offer. My email is in my profile.
Earlier quoted context omitted.
What does that have to do with JSON being an intermediary language and not the actual persistence part? What part of that don’t you understand and I’ll try to explain it for you
You're the one that doesn't understand. It's what makes you so edgy. Keep doing it.
Databases shouldn't be exciting. They should just work . The main reason webcrap works is because the databases underneath work. If the Javascript crowd had to manage data storage, nothing persistent would work reliably.
> Databases shouldn't be exciting. They should just work . With enough experience with the alternative, things that just work are exciting.
Earlier quoted context omitted.
Under InnoDB, because we’re not talking about file corruption but cases where MySQL would silently and irreversibly discard data rather than throwing an error. For example, inserting a value which is too large for the target data type - it truncates the value so that value is lost unless you have another copy or way to reconstruct it.
> For example, inserting a value which is too large for the target data type - it truncates the value I commented in another thread about this. It's not black or white whether that's a bug or a feature since: 1) not truncating causes the whole row to be rejected in Postgres, or with the relevant MySQL server setting 2) for many SaaS and social media apps, truncating that column type is fine, since typically that's a…
As someone who's trained a bunch of DBAs, here's how you should explain that this is a bug:
A database's job is to reliably store and retrieve data: that's why we talk about ACID since the whole concept is built around moving from one correct state to another. If we didn't care about getting back what we stored, we could just write flat files on disk and shrug when it breaks. Silently discarding some of the input breaks that contract.
Similarly, a core part of the SQL standard is about the database ensuring that values match the defined schema constraints. If we're going to allow silent truncation, the same reasoning would allow inserting foreign keys which don't exist, coercing non-numeric values into NULLs or other ways of “handling” non-numeric data types, replacing invalid dates with "0000" (oh, wait…), ignoring CHECKs (which MySQL did until 8.0.16), etc. If we're not doing that, we could just use MongoDB and stop pretending to be more than a blob store.
Rejecting the entire row is exactly what a DBA should want because it means that a) the database only contains the valid data it promised to save and b) the application team is immediately alerted to a mismatch between what their application assumes and how the database schema is actually configured — since there's been a breakdown in the migration process, there are likely other problems as well which might be more subtle. Especially in this century there's no excuse for not using a migration framework which makes the process of keeping the database schema in sync with the application automatic and reliable.
In one of the rare cases where data truncation is okay — and note that I've never encountered one of those in 3 decades where the users saw it as anything other than “This garbage software doesn't let us store more and that's why our department really runs on the Excel spreadsheet one of the admin assistants created” — the correct approach is to implement it at the application level so the user can see a fixed-length input field, warnings if they try to enter more, etc. and the application doesn't produce odd errors when, say, it stores a value and attempts to retrieve the same value only to be told it doesn't exist.