151–160 of 332 posts
Can someone from EdgeDB explain why the SQL isn't as simple as what I have below? What am I missing? Why is that cross join lateral necessary: SELECT title, ARRAY_SLICE(ARRAY_AGG(movie_actors.name WITHIN GROUP (order by movie_actors.credits_order asc)),0,5) avg(movie_reviews.score) FROM movie JOIN movie_actors on (movie.id = movie_actors.movie_id) JOIN person on (movie_Actors.person_id = person.id) JOIN movie_reviews…
Earlier quoted context omitted.
Am I right in reading this as the parent comment envisioning a “post” table and a “tag” table, and you’re suggest the “post” table just have a “tag” column?
I see just one table > Every post is tagged with a given category. There could be 100+ categories in the blog system and a blog post could be tagged with any number of these system categories. My point is, I don’t see SQL query as expensive for this kind of use case. There are easy and native ways to do it. In case you would like a top notch performance, Redis might be a way to do it. Even a reverse-index would achie…
+---------+-------+---------+-------+-----------+
| post_id | title | content | other | fields... |
+--------+------+
| tag_id | name |
+------------+---------+--------+
| tagging_id | post_id | tag_id |
SELECT post_id, count(1) AS count
FROM taggings
WHERE tag_id IN (3, 8, 255)
GROUP BY post_id
ORDER BY count DESC
And I don't see why that query suffers as you add tags...?
------------
EDIT responding to below [HN believes I am a problem user who should only be allowed to make so many comments per day]:
Well, assuming you're doing this because a user is interacting with your site via some kind of web interface, you can set the interface up to deliver you tag_id values directly, but you'll still need to do a join with the posts table so you can present a list of posts back to the user instead of a list of internal post_id values.
So I guess
SELECT t.post_id, count(1) AS count, p.title, p.url
FROM taggings t JOIN posts p ON t.post_id = p.post_id
...I feel like a graph database is a solution to an issue I've faced (and, continue to face) and it may just be because that I haven't spun one up and tried or that the documentation/examples don't stick out. But could someone confirm my feeling? If my feeling is correct, I'd enjoy verifying it with EdgeDB or the like. My example/requirement: I have a user wanting to find best-matching blog posts. Every post is tagged w…
I don't understand the benefit. It's just a query language on top of Postgres? It doesn't seem to have the performance characteristics of a graph database, while acting like it does. JOINS will still be expensive. You guys shouldn't use the word graph, misleading.
a graph database is not useful because of its query language, it's useful because of its performance characteristics when bringing linked data — it could never be performant on a Postgres backend.
Earlier quoted context omitted.
I see just one table > Every post is tagged with a given category. There could be 100+ categories in the blog system and a blog post could be tagged with any number of these system categories. My point is, I don’t see SQL query as expensive for this kind of use case. There are easy and native ways to do it. In case you would like a top notch performance, Redis might be a way to do it. Even a reverse-index would achie…
That's a standard many-to-many relationship that would normally be implemented by three tables: +---------+-------+---------+-------+-----------+ | post_id | title | content | other | fields... | +--------+------+ | tag_id | name | +------------+---------+--------+ | tagging_id | post_id | tag_id | But it seems like the core of the request is still something like: SELECT post_id, count(1) AS count FROM taggings WHERE…
EdgeQL seems like a custom graphQL. Any reasons you did not follow dgraph's DQL or graphQL-compatible language? https://dgraph.io/docs/get-started/
How does this compare against neo4j? When should I choose one instead of the other?
> We should not continue wasting our productivity with a database API architecture from the last century. Sorry, but dissing proven technology like this just makes me vomit. Show me _how_ you can beat SQL in performance and features on the frontpage, or I'm just happy to go along with what I already have.
What a terrible attitude to have, that's truly the worst possible interpretation. How's that dissing anything? They are saying they have a good abstraction that will make you more productive. While it might not be, this is literally what makes software the amazing tool it is, building layers of abstraction that make you more productive. You seem to have gotten it all wrong, how could building something on top of SQL…
It's an amazingly lazy and inconsiderate way to respond to people who've put a bunch of effort into building something.
EdgeDB co-founder Yury here. Ask me anything :) Live launch stream: https://www.youtube.com/watch?v=WRZ3o-NsU_4
do you have plans to integrate with prisma? it's almost a DIRECT translation of how the query is expressed in Prisma compared to edgedb. Googling quickly, it seems there is a ticket already. I wonder if this could be a low hanging fruit and a great growth channel since prisma is very popular. https://github.com/prisma/prisma/issues/10210
See also this reply by Colin: https://news.ycombinator.com/item?id=30293544