81–90 of 177 posts
Seems like a lot of what fauna does by storing documents isn’t really new, oracle, Postgres and others have provided this for a long time. I was really surprised by the performance of json queries [1], opens the doors to using Postgres as a client api cache, storing the payload in a table, and doing deserialization using (materialized) views. Difference seems to be the approach to minimize number of calls from your a…
This is a very interesting way to promote a product, credit to the author (who is an industry veteran it seems). I had no idea what Fauna was. I just clicked the link here because the title caught my eye (I work with databases quite a bit). The opening paragraph immediately grabbed my attention - "My first deep dive into SQL was in 1987, just before I became the first technical person at Microsoft to work on SQL Serv…
This is interesting, because I have the exact opposite response to these sorts of articles. I think any bias or personal interest should be declared upfront in media (articles, videos, podcasts, ...) rather than appear as a 'common consumer' talking about a pain point in a relatable way. It really rubs me the wrong way when an article ends with a bait-and-switch, where you realise the entire article was manufactured…
A site that's about "here's our product and why you might like it!" without getting into some "SQL, well you know, it has shortcomings" which is just unnecessary.
Earlier quoted context omitted.
The motivation behind first normal form is to keep the query language simple and powerful at the same time. Allowing nested tables would require extensions to the query language but wouldn’t give any additional expressive power since you can already express the same relationships using foreign keys. Also I dont see how it isn’t hierachical? Nested tables create a hierachical structure just like nested records in a hi…
It's not 1992 anymore. https://youtu.be/8Fb5Qgpr03g?si=Jc7dpuVgws3POiXA It may upset someone's sense of "purity", but the SQL standard and thoughts about the relational model have long since moved on from this dogmatic view of atoms, and no, foreign keys can't perfectly model what folks need. Eventually the rubber hits the road, theory and practice diverge, and different approaches are clearly needed. There is a plac…
But let me point out that hierachical databases (which document databases, xml etc are variants of) predate the relational model (and certainly predate Dates work) so it it worth to be aware of the challenges and limitations which caused the development of the relational model as an alternative.
Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…
The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…
Agreed, just parsing out the formatting so its "fewer lines" than traditional SQL soured me.
The expressions example is ridiculous, in Redshift I can do this all day?? SELECT 1 + 2 AS num1 , num1 * 2 AS num2 -- Literally no difference
Just learn SQL...
Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…
Usually, the error is a gotcha built into the language syntax (e.g. forgot the keyword "TO").
Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first, and relational was built in part to solve their problems. Document DBs just bring those problems back.
Disclaimer: I'm a core contributor to PRQL [1] and post about it a lot on HN. Apologies for jumping in on other people's threads, but for people interested in the headline, PRQL might be of interest. At PRQL[1] we believe that SQL is a combination of two things: 1. Relational Algebra, which is eternal because it's just maths, and 2. A language designed in the 70s that looks like COBOL. When people say that SQL will n…
The syntax comparison section will likely sour a lot of viewers who already know SQL. You try too hard to highlight how easy and terse PRQL is by putting comma-separated items on their own lines but in SQL you put each item on separate lines. It may be typical of many SQL users and formatters, but it leaves a poor taste in the mouth that you aren't interested in an actual comparison but in marketing. For those who al…
They style it as "4 lines vs 10 lines!" when it's actually 4 lines vs 4 lines.
# PRQL
from employees
select {id, first_name, age}
sort age
take 10
# Misleading SQL
SELECT
id,
first_name,
age
FROM
employees
ORDER BY
age
LIMIT
10
# Actual SQL
SELECT id, first_name, age
FROM employees
ORDER BY age
LIMIT 10
# PRQL
from employees
join b=benefits (==employee_id)
join side:left p=positions (p.id==employees.employee_id)
select {employees.employee_id, p.role, b.vision_coverage}
# Misleading SQL
SELECT
employees.employee_id,
p.role,
b.vision_coverage
FROM
employees
JOIN benefits AS b ON employees.employee_id = b.employee_id
LEFT JOIN positions AS p ON p.id = employees.employee_id
# Actual SQL
SELECT employees.employee_id, p.role, b.vision_coverage
FROM employees
JOIN benefits b USING employee_id
LEFT JOIN positions p USING employee_id
Fixed schemas are good. Document stores are bad. SQL is good. Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first , and relational was built in part to solve their problems. Document DBs just bring those problems back.
NoSQL databases aren’t unilaterally worse than relational ones. They just solve different problems.
Earlier quoted context omitted.
That first PRQL code sample is wonderfully readable.
It is! One suggestion to make it even more convincing: I'd love to see the SQL statement it compiles to.
WITH table_1 AS (
SELECT
customer_id,
total,
total - 0.8 AS _expr_0
FROM
invoices
WHERE
invoice_date >= DATE '1970-01-16'
),
table_0 AS (
SELECT
COALESCE(SUM(_expr_0), 0) AS sum_income,
customer_id
FROM
table_1
WHERE
_expr_0 > 1
GROUP BY
customer_id
ORDER BY
sum_income DESC
LIMIT
10
)
SELECT
c.customer_id,
CONCAT(c.last_name, ', ', c.first_name) AS name,
table_0.sum_income,
version() AS db_version
FROM
table_0
JOIN customers AS c ON table_0.customer_id = c.customer_id
ORDER BY
table_0.sum_income DESCFixed schemas are good. Document stores are bad. SQL is good. Stop doing this nonsense. It's a step backwards. As the intro points out, hierarchical and graph DBs came first , and relational was built in part to solve their problems. Document DBs just bring those problems back.
I saw it first hand 10 years ago, and had to do a migration.
Their justification for using mongo was that their system is very dynamic so their data changes a lot and sql based DBs dont allow that. I told them about DBA migrations and whatnot, but I just haven't been able to convince them.
It's sad seeing how they are digging into the same hole I had to digg out myself from a decade ago.