Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Can Do Better Than SQL

edgedb.com

Post reply on HN
Print view View original

421–430 of 466 posts

Re: We Can Do Better Than SQL

#421

Post by jolux »

013a wrote: post #407
jolux wrote: post #339

Earlier quoted context omitted.

That doesn’t prevent injection, and the solution to injection attacks is using parameterized queries and prepared statements, not switching to MongoDB. Plus ORMs (really query builders) already provide behavior like this against SQL databases anyway.

That's fair, but I didn't say it prevents injection: I said it prevents most injection attacks. MongoDB is absolutely still capable of being vulnerable to injection; its just harder, because it requires the client to provide an object which is parsed by your application with no data validation. In other words, SQL is vulnerable to injection by-default, because everything is a string, while you have to opt-in to being…

The difference as minimal. If you know the first thing about what you're doing with SQL you will use prepared statements. It's not some sort of arcane feature that nobody understands.

Re: We Can Do Better Than SQL

#422

Post by lmm »

jimbokun wrote: post #305
lmm wrote: post #116

Earlier quoted context omitted.

That's circular reasoning though. Why do you want your data to be in a relational database? Particularly if you're not actually using its features (I don't think I've ever seen a web application that actually got any value out of database-level transactions, for example). A different kind of datastore could offer you better performance and easier querying.

> (I don't think I've ever seen a web application that actually got any value out of database-level transactions, for example) You only ever have one user in your web applications at a time? > A different kind of datastore could offer you better performance and easier querying. Citation needed. The so called "NoSQL" systems manage to scale better because they have very constrained query models. So they are only "easi…

> You only ever have one user in your web applications at a time?

No, but database-level transactions don't help you deal with concurrent users. You don't keep a transaction open between showing the user an edit page and applying their changes (at least I hope you don't), your transactions can last at most through the web request-response cycle. So if you want actual transactional behaviour (e.g. a wiki with "another user is editing this page") you have to reimplement it yourself "in userspace".

> Citation needed.

SQL datastores are very open about the tradeoffs that they make for the sake of ACID isolation - the fact that the transaction isolation level is tuneable shows that, as does the fact that all serious SQL databases use MVCC.

Also MySQL had benchmarks showing that 75% of the time for a query by primary key was spent on parsing the SQL.

> The so called "NoSQL" systems manage to scale better because they have very constrained query models. So they are only "easier", perhaps, in the sense of supporting less functionality, but in most cases that leads to a big increase in complexity in the rest of the application code.

Not my experience, because the overwhelming majority of the time the code doesn't make any use of the complicated SQL functionality. I've literally never seen a cross join in use. I can count the number of times I've seen nontrivial aggregations in live code on one hand. The few times I've written recursive queries I found poor driver support, incompatibilities between different databases. So you pay the cost of flattening your data into the SQL table model, but most of the time you get no benefit from it.

There are pretty much three different kinds of queries: indexed lookups into raw data, indexed lookups into derived data (secondary indexes being a special case of this) and aggregations over a full table (table scans being a special case of this). A query model that represents those cases separately is easier to understand and work with, especially when it comes to understanding the performance. If your datastore supports server-side map-reduce style aggregations then you can literally execute arbitrary code in a "query", but you'll have a clear understanding that you're doing something different (with performance implications) from looking up a value by its indexed key.

Re: We Can Do Better Than SQL

#423

Post by emptysea »

013a wrote: post #420
Beefin wrote: post #419

Earlier quoted context omitted.

I wouldn't say arrays are bad, and the entire paradigm of data modeling in mongodb is to store your data based on your application usage patterns. if you have to query across multiple collections via a $lookup, then maybe you'd benefit from embedding the smaller of those collections into the former.

Maybe. But, as a general rule, I advise against arrays of unbounded size on documents (arrays of a known bounded size, say, containing enums to act as a multi-value flag, or email addresses on a user's account, or something like that, are fine). One example: We used mongodb to track the state of a general CSV import system. So, we'd have a document for each csv file a user imported, and on that document, we were stor…

Interesting, we ran into a very similar thing at my current place where we have a CSV importer storing results in mongo. Importantly it also stores the errors that occurred during the import.

In our case someone uploaded a _huge_ CSV with some misalignment in the columns so every row had an error.

The resulting the mongo document was larger the max document size (16MB?), so it couldn't even save to the database.

Mongo is painful to work with and I feel like I keep finding more reasons to hate it.

Re: We Can Do Better Than SQL

#424

Post by sanderjd »

0fcf8d3559a64c wrote: post #385
sanderjd wrote: post #289

Earlier quoted context omitted.

> It should be possible for an amateur to quickly write an SQL validator as a starting project ...why? SQL has been wildly paradigm-definingly useful for decades. It has driven hundreds of billions, perhaps trillions, of dollars of value. None of this hinges on the ability for an amateur to be able to write a validator for the language. It just seems like such a non-sequitur to me, such a strange thing to call out as…

>It has driven hundreds of billions, perhaps trillions, of dollars of value. The same can (almost) be said for Javascript. A language with a lot of foibles can still be successful if it is the only realistic mechanism to interact with the system.

No disagreement from me there! Though I personally like SQL more :)

Re: We Can Do Better Than SQL

#425

Post by fogetti »

zvrba wrote: post #393
isatty wrote: post #170

Earlier quoted context omitted.

> SQL is very hard to learn properly, with all of its gotchas and inconsistencies. I don't understand why though? I've been using SQL (Postgres for the most part but with a smattering of MySQL thrown in) for around 8(?) years, which isn't much in the grand scheme of things but I have not had anything that couldn't be resolved. I've written small straightforward queries to over 200 loc and never had a problem understa…

> In fact, ORMs have been a massive headache because I can think in SQL but not in whatever the creator of the ORM was thinking in. Yes, fully agree on ORMs. They DO have one nice feature though: simple CRUD operations are way less verbose than constructing SQL statements. What we lack is a better integration between the host language and the databse. Constructing a prepared statement from a string, setting parameter…

Just to let you know, those things are not needed at all if you use a different type of ORM, similar to ActiveRecord or Django ORM. It all depends on what you choose. So probably the first mistake was that you didn't do the homework of exploring ORMs maybe?

Re: We Can Do Better Than SQL

#426

Post by mathgladiator »

Zamicol wrote: post #196
mathgladiator wrote: post #96

Earlier quoted context omitted.

No, I'm with you and prefer SQL for many tasks. SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale". SQL as a language within other languages is a nightmare from a security standpoint, and if language integrated query was more common across languages earlier on then this wouldn't have been an issue. Databases generally depend on normalization, but normalization comes with inte…

What is a good "web scale" solution?

These days, anything.

The question is what is it going to cost in either licensing solutions or engineering effort.

Re: We Can Do Better Than SQL

#427

Post by mathgladiator »

brynjolf wrote: post #251
mathgladiator wrote: post #96

Earlier quoted context omitted.

No, I'm with you and prefer SQL for many tasks. SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale". SQL as a language within other languages is a nightmare from a security standpoint, and if language integrated query was more common across languages earlier on then this wouldn't have been an issue. Databases generally depend on normalization, but normalization comes with inte…

What are examples of those "easier things"?

MongoDB could be an example, but it introduces yet another empire.

Redis is also easier.

The key is what are you designing against. If you design against a DB, then you may find that scaling beyond a single host with gotchas. But, if you have the discipline to keep everything within a document, then you can scale up easier as the relationships between documents is more relaxed.

However, cross document indexing and what-not creates more problems, and that in and of itself is an interesting challenge.

Re: We Can Do Better Than SQL

#428

Post by sanderjd »

mannykannot wrote: post #363
sanderjd wrote: post #350

Earlier quoted context omitted.

That seems like a completely different point. (Unless I misunderstand what a "SQL validator" is, which is definitely possible.) I do think this way of utilizing SQL is a problem, but I would lay the blame for it at the feet of a lamentably widespread anti-intellectualism in the field. It is true that the relational model is not trivial and must be learned before SQL makes much sense. But it is not too much to expect…

I agree that someone who wants to be a practitioner in this field should understand the relational model, but the issue here is that SQL introduces inconsistencies and complications that are not inherent in the relational model, and, to some extent are avoidable. A justifiable emphasis on professionalism does not absolve SQL of these faults and does not render irrelevant attempts to find better language choices.

Sure, I don't disagree. My point is that the perfect is the enemy of the good, and SQL is the good.

Re: We Can Do Better Than SQL

#429

Post by int_19h »

gboss wrote: post #301
goto11 wrote: post #291

Earlier quoted context omitted.

> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

Slightly tangential but I really like Linq syntax. The only problem I have with it is that it is really hard to debug if there is a logic error. I often see developers write linq find out the record set they get back is incorrect and then break up the linq query to a nested if clause to get what they want.

That's a quality of tooling issue. And in Visual Studio, for example, you can set breakpoints on individual subexpressions in the query.

Re: We Can Do Better Than SQL

#430

Post by int_19h »

mannykannot wrote: post #342
goto11 wrote: post #291

Earlier quoted context omitted.

> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

You have piqued my curiosity, but what would a linq solution to this exercise look like?

Which particular exercise?
Post reply on HN