Rendered at 18:28:32 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
rsyring 1 days ago [-]
> From September 2026, Mathias Breistein has taken over as CEO, with a focus on new customer acquisition
Mathias, if you are here and listening, I'm interested but $35 / month is the wrong price point for this. $420 for year.
I can buy DataGrip for $261 for three years and it has a perpetual fallback license that would let me pay for the first year and then stop and just not get updates.
IMO, to start, you want your product to be so good and so reasonably priced that it's easy for someone to decide to give it a try. You are coming in with a uber premium price and I think that's going to severely hinder your customer acquisition efforts.
Also, I almost never get a license to a tool like this where I'm not entitled to keep using it if I stop paying for it. There is just too much incentive on the part of the vendor to just keep driving the price up to the breaking point. With a fallback license like JetBrains has, if they get unreasonable about price, I can just exit.
Finally, in the age of LLMs, if this gets popular and the price point is wrong, someone is going to do a good job of producing a competitor and make it open source or much less expensive. Make the official version a reasonable enough price that there is no reason to not support you to make it better.
Just my $0.02 but hope it helps at some level.
Finally, I looked at the website and there was no way to contact you to tell you this personally. So...might want to fix that. Small org, easy contact should be part of the perk.
rkr1410 1 days ago [-]
Yeah, I just looked at the price if it's anything I'm even remotely interested in paying if I found the trial enticing... and decided to not even bother with the trial. So there's this effect of a price set too high
gwbas1c 1 days ago [-]
I agree on the price. At least for my needs, I doubt I would be a heavy enough user to justify the price. (I probably would use this a handful of times a year; because I get similar-ish navigation in LINQPad.)
---
I did kick the tires with a free trial; and would probably recommend this to anyone who needs to navigate a SQL database in a point-and-click manner.
antonvs 1 days ago [-]
A free or cheaper tier for personal use, or use below a certain business size, could make sense here.
Agreed about the fallback. Paying monthly for a local tool with no fallback should give anyone pause.
rekabis 23 hours ago [-]
Came here to say something considerably simpler but essentially the same: for a solo dev, it’s just not affordable unless that solo dev does intense DBA work day in and day out or earns stupid money for the work they do.
ranger_danger 21 hours ago [-]
[dead]
kragen 2 days ago [-]
Eirik Bakke's Ultorg (SIEUFERD) is amazing and inspirational research, and I'm glad to see that it's finally available to the public after 17 years. It's one of those things that really makes you sit up and take notice of how much better our everyday software could have been.
However, I wouldn't be willing to try it under proprietary-software terms. Last week, I was thinking about eliciting open-source software with the Ultorg look and feel from an LLM, thus replicating Bakke's HCI research and enabling other HCI researchers to build on it, which won't be possible under a proprietary license.
> Eirik Bakke’s [SIEUFERD][0] (or, as he sometimes spells it, SIUEFERD) is a really interesting and promising generic database frontend, a “schema-independent database UI”. The elevator pitch is “a new kind
of graphical query interface [with] the power of SQL but the
ease-of-use of a spreadsheet”. (Unfortunately, he forgot to implement
the DDL part of SQL, just doing the DML part.)
I think the novel thing here, that I have not yet seen in any other database app, is the realization that normal SQL joins are not quite what you want in most cases.
Often, you are interested in nested results. "Give me all my customers with a list of their orders." However, when you do this with a join, you get a list of the orders with a copy of the customer information attached to each, instead. In Ultorg, you actually get the customer with a list of their orders nested in their row as a sub-table, but with that sub-table's headers cleverly floated to the top, so they're not repeated for each customer.
As a second trick, Ultorg manages to remember the relations, so the data is editable in the nested tables. (There are some limitations to this, I believe.)
I used the trial version of Ultorg at the beginning of the year (the example in the 2.1.4 changelog is based on my use case), and it was tons of fun to use. Ultorg is great. I wish I had discovered it right at the start of that small project.
Unfortunately, I do not have a regular use case for this, and for personal use and occasional unpaid hobby projects, Ultorg's license is not a good fit. So I check the website from time to time whether there's been a change to it; no luck so far.
I am no business expert, and I do not know how well Eirik is doing with the current model. However, I do have the impression that he underestimates how many people would have a use case in their private life for it, but not at $35/month. I think this could also help attract new commercial users. After all, it's much easier to convince your boss of purchasing a software if you have already built expertise by using it personally.
unshavedyak 1 days ago [-]
> for personal use and occasional unpaid hobby projects, Ultorg's license is not a good fit.
I had the same issue. I was enamored with the UI Ultorg presented for SQL. However once the pricing came out it felt.. harsh unless i was using a lot of SQL in my work, which i was not. If it was a Jetbrains style license i'd have one now, even though i rarely use DBs in this manner.
mamcx 1 days ago [-]
Yep, I have said for long that SQL `GROUP BY` should be that, instead of what is now (that is variation of SUMMARIZE).
UltraSane 1 days ago [-]
SQL forcing all results into a flat table is one of its biggest design flaws. It creates tremendous data duplication.
It's a "new database" (actually a layer on top of Postgres). It has a more ergonomic query language, and it returns results as nested structures rather than rows. So "give me all my customers with a list of their orders" returns what you want.
Unfortunately, the startup that was developing Gel got acqui-hired, and Gel's future is unclear.
Skeime 1 days ago [-]
This is the first link in this thread that points to something innovative, I think. Their UI screenshot does have nested results, for example. No commit to their open-source repository in 11 months is worrisome, though.
ctippett 1 days ago [-]
If anything a well designed database minimises data duplication. If your query returns duplicate data that's on the writer, not the language's fault.
Skeime 1 days ago [-]
It is the language's fault, because SQL offers no good way to get nested results. If you want to avoid the duplication, you can do multiple queries, but then you essentially have to do the join on the receiving end, which kind of defeats the purpose of having joins in SQL.
Alternatively, you might use functions to aggregate in the query, but they're not standard, as far I know, which means that interfaces in programming languages often do not support them. The best bet might be aggregating into JSON, but this removes quite a bit of the type information that values in SQL usually carry. (Also, the aggregation functions are generally less pleasant to write than standard joins.)
efromvt 1 days ago [-]
Yeah, ARRAY_AGG being an optional part of the standard is annoying, and in general the array handling functions have been very non-standardized and messy - it's getting better though!
treebeard901 16 hours ago [-]
Window functions such as PARTITION BY can accomplish nested results, with headers.. Etc.
win311fwg 1 days ago [-]
> because SQL offers no good way to get nested results
Because you don't need nested results. You can fire off another query.
Although I am venturing to guess that you feel you need nested queries because you're doing doing something stupid like trying to send SQL queries over the network where the cost of firing off another query becomes a great performance burden. But the answer to that is don't do that. SQL was specifically designed to be run on the same machine as your application.
If you need to present the data to network clients where nesting is necessary for performance reasons, turn your application into the network database service that produces nested data (the "API server" as the kids call it). Leave the SQL as an implementation detail hidden behind the scenes.
Skeime 1 days ago [-]
I do want to be presented with nested results in the end, though!
As I mentioned in the previous post, I am aware that this can be done with multiple queries and post-processing, but then I am implementing what essentially amounts to a join myself (of maybe I have something like an ORM do it for me). In any case, my data processing is now split up in two places.
And the point of Ultorg is that it provides an interface that does this post-processing into a nested representation. Except maybe for Gel (mentioned somewhere else here), I have not seen this in any other general interface for relational databases. If SQL supported nested results, this surely would be different.
win311fwg 1 days ago [-]
> my data processing is now split up in two places.
It is a higher level concern so that isn't a bad thing. SQL is focused on giving you a view of your data. Whereas you want to combine many different views. That is where composing many different queries should be seen as quite natural at the interface point, not a shortcoming of SQL. If that composition isn't natural, you may want to take a closer look at your application's architecture.
> but then I am implementing what essentially amounts to a join myself
Joins and aggregated views are very different concepts. I think this misunderstanding, which is one I've seen many times before, stems from the hacks used to work around the aforementioned problems. Many have come to believe those hacks actually how SQL is designed to be used, not the hacks that they are.
> I have not seen this in any other general interface for relational databases.
Oracle has their thing. Its name escapes me at the moment. Postgres has json_agg/jsonb_agg and similarly SQL itself has array_agg. Lots of options out there.
But it's not only a question of if it can be done, but if it should be done. There are a lot of other advantages to moving query aggregation out into another application. There is a reason why we stopped sticking SQL servers directly in front of the clients and it isn't just because of SQL using a table representation.
Skeime 10 hours ago [-]
I think we will just end up disagreeing here. If I want to get out a presentation combining data from two tables in a one-to-many relationship, potentially filtered by fields in both tables, I see no really convincing option. To be explicit, I'll use "Give me a list of all my customers in Oregon who have made a purchase within the last year together with those purchases" as an example.
I can write a single join in SQL to get this, but then the customer information will be repeated on each purchase line. For my report I will also need to group orders from the same customer together. So now I have asked my database to duplicate the customer information across rows, only to deduplicate the data in my application again.
I can create two SQL queries, one for the customers, one for the purchases. I will still need to use joins (or WHERE-EXISTS clauses), because I do not want to extract all my customers and/or purchases from the database. Then, in the application I need to combine the results of those two queries. This will require me to implement the same join (or at least, its matching logic) yet again.
Neither of these really seem all that great to me. Of course, one can work around these limitations, many database adapters do. But in my opinion, this does not mean that SQL should not have provided a native solution for this. (There are tons of other things it could have left out as well, by that logic.)
The agg functions are probably the closest thing we have. I have mentioned my gripe with the JSON versions before, they lose valuable type information due to JSON's limited data model. The array_agg version is usually not very ergonomic on the receiving end. Both are also more cumbersome to write in SQL than I would like.
For what it's worth, I also think that SQL teaching generally emphasizes joins as the natural way to work with relational databases way to much. The agg functions might appear almost as an afterthought at the very end. (To be fair to the creators of teaching materials, to me, they also appear as an afterthought in SQL itself.)
win311fwg 9 hours ago [-]
> To be explicit, I'll use "Give me a list of all my customers in Oregon who have made a purchase within the last year together with those purchases" as an example.
Yes, this maps quite nicely to SQL. Consider this pseudocode[1]:
for customer in (select distinct c.customer_id, c.name from customers c natural join purchases p natural join addresses a where p.purchased_at >= last_year and a.city = 'Oregon') {
println(customer.name)
for purchase in (select date, amount from purchases where customer_id = customer.customer_id and purchased_at >= last_year) {
println("\t"+purchase.date+": "+purchase.amount)
}
println()
}
I know, you're already recoiling in horror. But that's because you've grown accustomed to having to deal with shitty implementations of SQL. It is recognized that you cannot actually write code like that under those shitty implementations because your program will quickly grind to a halt as soon as you gain a few customers, but the point here is to stop using shitty SQL implementations and embrace SQL as it as it was actually intended to be used.
> But in my opinion, this does not mean that SQL should not have provided a native solution for this.
SQL does provide a native solution. But it seems your argument is, perhaps, that it should formally define a way to hack around shitty implementations? Why not use the right tool for the job instead?
> I also think that SQL teaching generally emphasizes joins as the natural way to work with relational databases way to much.
Agreed, and I am suggesting that is because of the hacks required to work around the reasons why you cannot write the above code under shitty implementations, which has lead to many to conflate joins and view aggregation.
If you want something like the above except using a declarative language instead then you can put something like GraphQL in front of it. What are you really gaining by turning SQL into GraphQL? SQL is not intended for graph databases. It is a different tool for a different job.
[1] The need for distinct here is SQL's actual flaw. If it were truly relational like it likes to pretend to claim to be that would be unnecessary. It brought the relational calculus but not the relational algebra, which leaves a funny impedance mismatch. You can deal with that in the small scale well enough, but as queries become complex they become hard to reason about because they don't behave like the expression suggests. Which serves as a good corollary as to why turning SQL into GraphQL is unwise when it doesn't have a graph foundation. Primitives best match the primitives. You can layer the abstractions on top, where you can take responsibility for the leaks, as your specific needs dictate.
achr2 1 days ago [-]
It minimizes data storage duplication, but not reading. The language does not have a simple way to receive unique records across N-1 joins.
UltraSane 12 hours ago [-]
It is actually pretty weird how much SQL emphasizes normalization of stored data but then gleefully denormalizes the data returned by a query.
imtringued 1 days ago [-]
No, that's still the SQL languages' fault because you cannot return multiple tables in a single query.
Half the reason why ORMs have trouble has to do with the fact that you need to fetch has many relations via a second select.
Beyond that, it's the GPPL languages' fault that it doesn't support object or class fragments which are needed to support queries that return a subset of an object.
If people bothered fixing these two issues, then ORMs would be great.
win311fwg 1 days ago [-]
SQL's biggest design flaw was rejecting the relational model, which leads to the join problems the earlier comment talks about.
The second biggest flaw, which isn't really about SQL itself but in implementation, was attaching SQL to the network where latency starts to become a problem. That requires hacks to work around. This is likely this is why you're seeing data duplication — trading all that duplication to avoid the latency problems that wouldn't be a problem if you kept it on the same machine like SQL originally intended.
cgio 1 days ago [-]
This use case is pretty standard in olap such as ease, with writeback and calcs too.
akshayrajeshwar 1 days ago [-]
Previously used it and it's AMAZING given you have data stored with good practices, e.g. with unique IDs that are consistent among many databases/sheets. I found it's easier to begin with Ultorg's usecase in mind than to migrate existing files to fit its use.
And I do agree with the criticisms mentioned in the thread. Ultorg is solving a lot of problems of data organisation and context awareness, so starting a business with a perpetual license would be awesome.
Guess I just don't wanna lose access to the tool once I have all the tailored files and fail to pay again.
Should mention that Eirik is a joy talk to and will quite possibly accommodate you. All the best to him.
NetMageSCW 2 days ago [-]
A small desktop app that is a subscription rubs me the wrong way.
aetherspawn 2 days ago [-]
I agree, it’s novel but please give me a perpetual version that costs like $500 and I’ll buy it. Hate subs.
dymk 1 days ago [-]
Problem is, only you and two other people would buy it.
convict 1 days ago [-]
As long as it doesn't stop other people from buying subscriptions, is it really a problem?
aetherspawn 1 days ago [-]
Well that’s an extra $1,500.
maxloh 1 days ago [-]
Someone just posted an open-source alternative earlier today. Its UI looks better too.
You can kinda-sorta get similar navigation in LINQPad. (But that requires constructing queries using C# and using an ORM like Entity Framework, which may be beyond the technical capabilities of the target audience.)
I personally would prefer a web-based version instead of a desktop version.
patates 1 days ago [-]
I like its flexibility but nothing beats LINQPad and its .Dump() method on that front.
racl101 1 days ago [-]
Would definitely use this if I was a data person. Overkill for a web developer tough.
polskibus 1 days ago [-]
Isn’t this like a pivot table, that many advanced BI solutions (that have a modeler inside) already have ?
wodenokoto 1 days ago [-]
It is and it isn't.
It looks like a polished thing that from a UX perspective sits between a spreadsheet and PowerBI
It let's any user with DB access build reports pretty close to how you'd edit a spreadsheet and without having to build pipelines in PowerBI and setup ingestion etc, etc.
The closest thing I've seen here is the old Tableu Desktop, but this one is more focused on tables than figures.
Question: Is there any way to customise the interface like add extra buttons, for example to export an invoice?
eviks 16 hours ago [-]
> Ultorg is an efficient, spreadsheet-like UI for relational databases.
Where is efficiency in UI if it has the same space wasting 0-filling design as everything else. At east in Excel you can mitigate some of it, but this app seems more auto,magical
> Dynamic Autolayout. To retain sanity, it is essential not to have to spend time tweaking formatting settings for each individual field, or for every new database query.
> Ultorg eliminates such hard, manual labor, by analyzing your data on the fly and deriving carefully tuned defaults.
Skeime 9 hours ago [-]
What do you mean by "0-filling design"?
I find Ultorg's representation to be quite compact, usually. If you have a view with one column containing lots of nested results, the other columns will be mostly empty, but then the table layout might be the wrong choice, and other layout options are available.
eviks 8 hours ago [-]
I mean the pointless zeros in
1.00
2.00
3.10
which only prevent you from noticing when a number has real decimals
> I find Ultorg's representation to be quite compact, usually.
Check the website's first screenshot - the 2nd column the longest data point - 693 blue bar - takes less space than all the whitespace around it.
Or the tree view - check out how much space is wasted for the main indentation level - "Recycle bin". You could fit the whole extra data column in that space for something useful
Skeime 4 hours ago [-]
Ah, I see about the zeros. I think there are some options for this.
The blue bar: there might be a red bar pointing to the left out of view that forces the white space between the bars and the numbers. There will be some extra white space to the left of the numbers, as nested tables are slightly indented (compare the indentation of the customer names and the products)—I think this is a good way of subtly showing the structure.
Tree view: “Recycle bin” does not have an arrow to unfold it but other items at its level do, so space for an arrow is reserved. Therefore it seems overly indented. (I am not bothered by this; if the actual tables are very wide, the entire side bar can be hidden, as far as I remember.)
I honestly found that main part of the interface strikes a very good balance between denseness and readability. And in any case, it is my experience (from just using the trial!) that Eirik can be quite swift about implementing features when there’s user demand. I imagine that extra number formatting options or reduced white space would be very much in the cards.
eviks 4 hours ago [-]
> there might be a red bar pointing to the left
There is already red bar above, it doesn't explain the waste, it's too small. But also it doesn't need to point to the left of the same spot, you can move it to the right to grow left - will be even easier to compare the absolut sizes.
> as nested tables are slightly indented
For nothing. Compare indentation of Product and Qty - both indented, so the indentation of Product is useless in signaling "nested". Headers is the only "reliable" place to read that info
> does not have an arrow
which doesn't need to be so big, you anyway should be able collapse/expand by clicking on the whole big field
> Therefore it seems overly indented
No, it is overly indented because the indent is too wide, especially for the first level - it shouldn't even exist, it's pointless separating the only Root from it's children with the same space as further levels where you can get confused, it's like the common fail of Jsons (which must have root {}) of wasting indentation space for each line
> entire side bar can be hidden.
Which is also no solution to this waste. Instead it should have a "condensed view" where you can still read the first couple of letters of Cat/Cust/Empl etc. If you want to be binary - either the tree is useful and should be visible at the limit and only disappera when you really need the last 1-2 columns it displaces, or it's not, and shouldn't be shown at all. That's useful efficiency
Skeime 3 hours ago [-]
If you scroll down on the landing page, there are tons of cases with blue bars only going in one direction; I think the distance between the numbers and the bars is quite reasonable there. When I speak of red bars, I assume that there is a red bar of significant size somewhere down that column, resulting in the space here. That said, I would agree that this is not necessarily the best visualization to begin with; I don't think I would use it at all.
The entire "Line items" subtable is indented: its internal horizontal lines do not stretch all the way to the vertical line at the beginning of "Line items". However, the horizontal lines between the line items for different orders do. This subtly highlights where one order ends and the next begins; I think its quite clever. Also, the "Qty" could be made thinner if you wanted. But in the screenshot there is still space available to the right, so its not vital. (Also, there might be a three-digit Qty further down the table, which would make this the right width.)
I don't find the "Folders" side bar that vital and I'm sure it could be improved. When saying that I think the interface strikes a good balance, I'm focusing on the main view. However, I think that there could be extra root-level items if you add further data sources, and I also think that you can make the sidebar thinner, at which point you will only see Cat, Cust, etc. For a main screenshot having the full names visible does seem cleaner, though. (I'm not entirely sure that all of this is correct. I cannot test it--unfortunately, while I think that Ultorg is very smartly designed in many places, its license cost is not justifiable for my limited use cases.)
velcrovan 1 days ago [-]
Wild that it supports just about everything except SQLite, the most widely used database in the world and the easiest to support
dethos 1 days ago [-]
Also noticed it. I guess that support will eventually land.
edbaskerville 1 days ago [-]
What's the patent situation?
kragen 15 hours ago [-]
Ultorg is mostly UX research that Bakke published in 02009 when he was working on his Master's Thesis at CSAIL. I haven't heard of any patents on it, but any patents that cover the version of SIEUFERD he published at the time would have had to be applied for by 02010 (02009 outside the US), meaning they'd expire by 02030 (02029). And I think it would have been pretty difficult to get a patent on the things they added later, like adding crosstabs to it.
Having published it so long ago means that it's excellent prior art for patents others might try to use against Ultorg or Ultorg clones.
BrenBarn 1 days ago [-]
I've wanted something like this for a really long time. Unfortunately I'll never use this because there's no way I'm going to pay for it, let alone pay an ongoing subscription fee, but it looks pretty cool.
The screenshots looks nice, but the text on the landing page does make me wonder if the whole thing is just a pile of slop.
mapcars 1 days ago [-]
Any features worth to switch from DBeaver?
Stitch4223 1 days ago [-]
Please approach this the other way around: try both and share your preferences here.
These seem to be entirely different tools. Ultorg is a generic relational gui (like Bento, Access and so on), dbeaver is a database admin tool centered around writing SQL and managing tables.
Mathias, if you are here and listening, I'm interested but $35 / month is the wrong price point for this. $420 for year.
I can buy DataGrip for $261 for three years and it has a perpetual fallback license that would let me pay for the first year and then stop and just not get updates.
IMO, to start, you want your product to be so good and so reasonably priced that it's easy for someone to decide to give it a try. You are coming in with a uber premium price and I think that's going to severely hinder your customer acquisition efforts.
Also, I almost never get a license to a tool like this where I'm not entitled to keep using it if I stop paying for it. There is just too much incentive on the part of the vendor to just keep driving the price up to the breaking point. With a fallback license like JetBrains has, if they get unreasonable about price, I can just exit.
Finally, in the age of LLMs, if this gets popular and the price point is wrong, someone is going to do a good job of producing a competitor and make it open source or much less expensive. Make the official version a reasonable enough price that there is no reason to not support you to make it better.
Just my $0.02 but hope it helps at some level.
Finally, I looked at the website and there was no way to contact you to tell you this personally. So...might want to fix that. Small org, easy contact should be part of the perk.
---
I did kick the tires with a free trial; and would probably recommend this to anyone who needs to navigate a SQL database in a point-and-click manner.
Agreed about the fallback. Paying monthly for a local tool with no fallback should give anyone pause.
However, I wouldn't be willing to try it under proprietary-software terms. Last week, I was thinking about eliciting open-source software with the Ultorg look and feel from an LLM, thus replicating Bakke's HCI research and enabling other HCI researchers to build on it, which won't be possible under a proprietary license.
My notes on Ultorg may be of interest; you can
and read sieuferd.md (5200 words).The introduction:
> Eirik Bakke’s [SIEUFERD][0] (or, as he sometimes spells it, SIUEFERD) is a really interesting and promising generic database frontend, a “schema-independent database UI”. The elevator pitch is “a new kind of graphical query interface [with] the power of SQL but the ease-of-use of a spreadsheet”. (Unfortunately, he forgot to implement the DDL part of SQL, just doing the DML part.)
I can highly recommend Bakke's 5-minute talk on it from 10 years ago at https://vimeo.com/173726371.
Often, you are interested in nested results. "Give me all my customers with a list of their orders." However, when you do this with a join, you get a list of the orders with a copy of the customer information attached to each, instead. In Ultorg, you actually get the customer with a list of their orders nested in their row as a sub-table, but with that sub-table's headers cleverly floated to the top, so they're not repeated for each customer.
As a second trick, Ultorg manages to remember the relations, so the data is editable in the nested tables. (There are some limitations to this, I believe.)
I used the trial version of Ultorg at the beginning of the year (the example in the 2.1.4 changelog is based on my use case), and it was tons of fun to use. Ultorg is great. I wish I had discovered it right at the start of that small project.
Unfortunately, I do not have a regular use case for this, and for personal use and occasional unpaid hobby projects, Ultorg's license is not a good fit. So I check the website from time to time whether there's been a change to it; no luck so far.
I am no business expert, and I do not know how well Eirik is doing with the current model. However, I do have the impression that he underestimates how many people would have a use case in their private life for it, but not at $35/month. I think this could also help attract new commercial users. After all, it's much easier to convince your boss of purchasing a software if you have already built expertise by using it personally.
I had the same issue. I was enamored with the UI Ultorg presented for SQL. However once the pricing came out it felt.. harsh unless i was using a lot of SQL in my work, which i was not. If it was a Jetbrains style license i'd have one now, even though i rarely use DBs in this manner.
It's a "new database" (actually a layer on top of Postgres). It has a more ergonomic query language, and it returns results as nested structures rather than rows. So "give me all my customers with a list of their orders" returns what you want.
Unfortunately, the startup that was developing Gel got acqui-hired, and Gel's future is unclear.
Alternatively, you might use functions to aggregate in the query, but they're not standard, as far I know, which means that interfaces in programming languages often do not support them. The best bet might be aggregating into JSON, but this removes quite a bit of the type information that values in SQL usually carry. (Also, the aggregation functions are generally less pleasant to write than standard joins.)
Because you don't need nested results. You can fire off another query.
Although I am venturing to guess that you feel you need nested queries because you're doing doing something stupid like trying to send SQL queries over the network where the cost of firing off another query becomes a great performance burden. But the answer to that is don't do that. SQL was specifically designed to be run on the same machine as your application.
If you need to present the data to network clients where nesting is necessary for performance reasons, turn your application into the network database service that produces nested data (the "API server" as the kids call it). Leave the SQL as an implementation detail hidden behind the scenes.
As I mentioned in the previous post, I am aware that this can be done with multiple queries and post-processing, but then I am implementing what essentially amounts to a join myself (of maybe I have something like an ORM do it for me). In any case, my data processing is now split up in two places.
And the point of Ultorg is that it provides an interface that does this post-processing into a nested representation. Except maybe for Gel (mentioned somewhere else here), I have not seen this in any other general interface for relational databases. If SQL supported nested results, this surely would be different.
It is a higher level concern so that isn't a bad thing. SQL is focused on giving you a view of your data. Whereas you want to combine many different views. That is where composing many different queries should be seen as quite natural at the interface point, not a shortcoming of SQL. If that composition isn't natural, you may want to take a closer look at your application's architecture.
> but then I am implementing what essentially amounts to a join myself
Joins and aggregated views are very different concepts. I think this misunderstanding, which is one I've seen many times before, stems from the hacks used to work around the aforementioned problems. Many have come to believe those hacks actually how SQL is designed to be used, not the hacks that they are.
> I have not seen this in any other general interface for relational databases.
Oracle has their thing. Its name escapes me at the moment. Postgres has json_agg/jsonb_agg and similarly SQL itself has array_agg. Lots of options out there.
But it's not only a question of if it can be done, but if it should be done. There are a lot of other advantages to moving query aggregation out into another application. There is a reason why we stopped sticking SQL servers directly in front of the clients and it isn't just because of SQL using a table representation.
I can write a single join in SQL to get this, but then the customer information will be repeated on each purchase line. For my report I will also need to group orders from the same customer together. So now I have asked my database to duplicate the customer information across rows, only to deduplicate the data in my application again.
I can create two SQL queries, one for the customers, one for the purchases. I will still need to use joins (or WHERE-EXISTS clauses), because I do not want to extract all my customers and/or purchases from the database. Then, in the application I need to combine the results of those two queries. This will require me to implement the same join (or at least, its matching logic) yet again.
Neither of these really seem all that great to me. Of course, one can work around these limitations, many database adapters do. But in my opinion, this does not mean that SQL should not have provided a native solution for this. (There are tons of other things it could have left out as well, by that logic.)
The agg functions are probably the closest thing we have. I have mentioned my gripe with the JSON versions before, they lose valuable type information due to JSON's limited data model. The array_agg version is usually not very ergonomic on the receiving end. Both are also more cumbersome to write in SQL than I would like.
For what it's worth, I also think that SQL teaching generally emphasizes joins as the natural way to work with relational databases way to much. The agg functions might appear almost as an afterthought at the very end. (To be fair to the creators of teaching materials, to me, they also appear as an afterthought in SQL itself.)
Yes, this maps quite nicely to SQL. Consider this pseudocode[1]:
I know, you're already recoiling in horror. But that's because you've grown accustomed to having to deal with shitty implementations of SQL. It is recognized that you cannot actually write code like that under those shitty implementations because your program will quickly grind to a halt as soon as you gain a few customers, but the point here is to stop using shitty SQL implementations and embrace SQL as it as it was actually intended to be used.> But in my opinion, this does not mean that SQL should not have provided a native solution for this.
SQL does provide a native solution. But it seems your argument is, perhaps, that it should formally define a way to hack around shitty implementations? Why not use the right tool for the job instead?
> I also think that SQL teaching generally emphasizes joins as the natural way to work with relational databases way to much.
Agreed, and I am suggesting that is because of the hacks required to work around the reasons why you cannot write the above code under shitty implementations, which has lead to many to conflate joins and view aggregation.
If you want something like the above except using a declarative language instead then you can put something like GraphQL in front of it. What are you really gaining by turning SQL into GraphQL? SQL is not intended for graph databases. It is a different tool for a different job.
[1] The need for distinct here is SQL's actual flaw. If it were truly relational like it likes to pretend to claim to be that would be unnecessary. It brought the relational calculus but not the relational algebra, which leaves a funny impedance mismatch. You can deal with that in the small scale well enough, but as queries become complex they become hard to reason about because they don't behave like the expression suggests. Which serves as a good corollary as to why turning SQL into GraphQL is unwise when it doesn't have a graph foundation. Primitives best match the primitives. You can layer the abstractions on top, where you can take responsibility for the leaks, as your specific needs dictate.
Half the reason why ORMs have trouble has to do with the fact that you need to fetch has many relations via a second select.
Beyond that, it's the GPPL languages' fault that it doesn't support object or class fragments which are needed to support queries that return a subset of an object.
If people bothered fixing these two issues, then ORMs would be great.
The second biggest flaw, which isn't really about SQL itself but in implementation, was attaching SQL to the network where latency starts to become a problem. That requires hacks to work around. This is likely this is why you're seeing data duplication — trading all that duplication to avoid the latency problems that wouldn't be a problem if you kept it on the same machine like SQL originally intended.
And I do agree with the criticisms mentioned in the thread. Ultorg is solving a lot of problems of data organisation and context awareness, so starting a business with a perpetual license would be awesome.
Guess I just don't wanna lose access to the tool once I have all the tailored files and fail to pay again.
Should mention that Eirik is a joy talk to and will quite possibly accommodate you. All the best to him.
https://news.ycombinator.com/item?id=50427934
You can kinda-sorta get similar navigation in LINQPad. (But that requires constructing queries using C# and using an ORM like Entity Framework, which may be beyond the technical capabilities of the target audience.)
I personally would prefer a web-based version instead of a desktop version.
It looks like a polished thing that from a UX perspective sits between a spreadsheet and PowerBI
It let's any user with DB access build reports pretty close to how you'd edit a spreadsheet and without having to build pipelines in PowerBI and setup ingestion etc, etc.
The closest thing I've seen here is the old Tableu Desktop, but this one is more focused on tables than figures.
Where is efficiency in UI if it has the same space wasting 0-filling design as everything else. At east in Excel you can mitigate some of it, but this app seems more auto,magical
> Dynamic Autolayout. To retain sanity, it is essential not to have to spend time tweaking formatting settings for each individual field, or for every new database query.
> Ultorg eliminates such hard, manual labor, by analyzing your data on the fly and deriving carefully tuned defaults.
I find Ultorg's representation to be quite compact, usually. If you have a view with one column containing lots of nested results, the other columns will be mostly empty, but then the table layout might be the wrong choice, and other layout options are available.
1.00
2.00
3.10
which only prevent you from noticing when a number has real decimals
> I find Ultorg's representation to be quite compact, usually.
Check the website's first screenshot - the 2nd column the longest data point - 693 blue bar - takes less space than all the whitespace around it.
Or the tree view - check out how much space is wasted for the main indentation level - "Recycle bin". You could fit the whole extra data column in that space for something useful
The blue bar: there might be a red bar pointing to the left out of view that forces the white space between the bars and the numbers. There will be some extra white space to the left of the numbers, as nested tables are slightly indented (compare the indentation of the customer names and the products)—I think this is a good way of subtly showing the structure.
Tree view: “Recycle bin” does not have an arrow to unfold it but other items at its level do, so space for an arrow is reserved. Therefore it seems overly indented. (I am not bothered by this; if the actual tables are very wide, the entire side bar can be hidden, as far as I remember.)
I honestly found that main part of the interface strikes a very good balance between denseness and readability. And in any case, it is my experience (from just using the trial!) that Eirik can be quite swift about implementing features when there’s user demand. I imagine that extra number formatting options or reduced white space would be very much in the cards.
There is already red bar above, it doesn't explain the waste, it's too small. But also it doesn't need to point to the left of the same spot, you can move it to the right to grow left - will be even easier to compare the absolut sizes.
> as nested tables are slightly indented
For nothing. Compare indentation of Product and Qty - both indented, so the indentation of Product is useless in signaling "nested". Headers is the only "reliable" place to read that info
> does not have an arrow
which doesn't need to be so big, you anyway should be able collapse/expand by clicking on the whole big field
> Therefore it seems overly indented
No, it is overly indented because the indent is too wide, especially for the first level - it shouldn't even exist, it's pointless separating the only Root from it's children with the same space as further levels where you can get confused, it's like the common fail of Jsons (which must have root {}) of wasting indentation space for each line
> entire side bar can be hidden.
Which is also no solution to this waste. Instead it should have a "condensed view" where you can still read the first couple of letters of Cat/Cust/Empl etc. If you want to be binary - either the tree is useful and should be visible at the limit and only disappera when you really need the last 1-2 columns it displaces, or it's not, and shouldn't be shown at all. That's useful efficiency
The entire "Line items" subtable is indented: its internal horizontal lines do not stretch all the way to the vertical line at the beginning of "Line items". However, the horizontal lines between the line items for different orders do. This subtly highlights where one order ends and the next begins; I think its quite clever. Also, the "Qty" could be made thinner if you wanted. But in the screenshot there is still space available to the right, so its not vital. (Also, there might be a three-digit Qty further down the table, which would make this the right width.)
I don't find the "Folders" side bar that vital and I'm sure it could be improved. When saying that I think the interface strikes a good balance, I'm focusing on the main view. However, I think that there could be extra root-level items if you add further data sources, and I also think that you can make the sidebar thinner, at which point you will only see Cat, Cust, etc. For a main screenshot having the full names visible does seem cleaner, though. (I'm not entirely sure that all of this is correct. I cannot test it--unfortunately, while I think that Ultorg is very smartly designed in many places, its license cost is not justifiable for my limited use cases.)
Having published it so long ago means that it's excellent prior art for patents others might try to use against Ultorg or Ultorg clones.
2022 (255 points, 68 comments) https://news.ycombinator.com/item?id=31551328
These seem to be entirely different tools. Ultorg is a generic relational gui (like Bento, Access and so on), dbeaver is a database admin tool centered around writing SQL and managing tables.