3 ms·

That data cleanup caveat is an important lesson — thank you so much for sharing your hard lessons learned. I actually don't know SQL very well (coming from des

That data cleanup caveat is an important lesson — thank you so much for sharing your hard lessons learned. I actually don't know SQL very well (coming from design), so something like Couch feel more intuitive to set up as it looks and feels like JS / JSON, with neat additions like views. I think I'll keep using Couchdb for my tiny projects, with the caveat that "if something gets bigger and more well-defined, start learning SQL" (or at least properly learn Supabase)

gwbas1c 3y ago
> I actually don't know SQL very well That's a huge, huge gap in your skillset. SQL databases are generally the one-size, fits-all of databases. There's good reasons (very good reasons) to use alternate databases; but they tend to be outside of the primary use cases of an application. One of the very important features of SQL is that how you query your data isn't tied to the structures that are convenient for a particular use case. Basically, the problem with using CouchDB and MongoDB as a general purpose database is that you're storing and querying data structures, or documents. It's easy early in a project, when your use cases are small. The problem comes later in the project, when a requirement comes to query a data structure that's deeply nested inside of a document. This can incur a rather substantial performance penalty, unless you denormalize your data. For example, when I used to go to MongoDB conferences, they used the example of a message board, where all messages in a post were stored in the same document. (For example, imagine that all messages in this thread are stored in a single document.) The problem then comes when you need to support a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c, that lists all posts that I've made. In the case of SQL, supporting a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c is merely writing a new query and updating an index. It doesn't require denormalization or scanning many documents. > I actually don't know SQL very well Another reason why it's important to understand SQL basics comes from being able to write code that performs well, within reason. I constantly inherit code that uses an ORM (library that translates between SQL and objects), and the code just can't perform. The original authors didn't know SQL at all, and just assumed that the ORM would do the heavy lifting for them. > I actually don't know SQL very well You don't really need to know much SQL to get by: Just four commands, "select, insert, update, delete," (and upserts) and then understand joins. Understand transactions, and you're all set. You can leave the more advanced features to when you need an advanced database feature.

gwbas1c 3y ago

> I actually don't know SQL very well That's a huge, huge gap in your skillset. SQL databases are generally the one-size, fits-all of databases. There's good reasons (very good reasons) to use alternate databases; but they tend to be outside of the primary use cases of an application. One of the very important features of SQL is that how you query your data isn't tied to the structures that are convenient for a particular use case. Basically, the problem with using CouchDB and MongoDB as a general purpose database is that you're storing and querying data structures, or documents. It's easy early in a project, when your use cases are small. The problem comes later in the project, when a requirement comes to query a data structure that's deeply nested inside of a document. This can incur a rather substantial performance penalty, unless you denormalize your data. For example, when I used to go to MongoDB conferences, they used the example of a message board, where all messages in a post were stored in the same document. (For example, imagine that all messages in this thread are stored in a single document.) The problem then comes when you need to support a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c, that lists all posts that I've made. In the case of SQL, supporting a page like https://news.ycombinator.com/threads?id=gwbas1c https://news.ycombinator.com/threads?id=gwbas1c is merely writing a new query and updating an index. It doesn't require denormalization or scanning many documents. > I actually don't know SQL very well Another reason why it's important to understand SQL basics comes from being able to write code that performs well, within reason. I constantly inherit code that uses an ORM (library that translates between SQL and objects), and the code just can't perform. The original authors didn't know SQL at all, and just assumed that the ORM would do the heavy lifting for them. > I actually don't know SQL very well You don't really need to know much SQL to get by: Just four commands, "select, insert, update, delete," (and upserts) and then understand joins. Understand transactions, and you're all set. You can leave the more advanced features to when you need an advanced database feature.