3 ms·

I would still use dBeaver because it allows me to edit data like Excel. And the fact that it works brilliantly on Linux. I'm not sure why more db tools don't f

I would still use dBeaver because it allows me to edit data like Excel. And the fact that it works brilliantly on Linux. I'm not sure why more db tools don't follow that paradigm.

wsh91 11y ago
Truth! Also, for its support of alternative databases like Mongo and Cassandra.
jmnicolas 11y ago
Because when you have a couple million rows in a table, you don't want to edit it à la Excel ;-)
- sandGorgon 11y ago
  not all kinds of editing are changing a billion rows at a time. Sometimes, you just want to change a few rows and few columns. I have actually used dbeaver as an order management system, while my front end caught up.
  - PudgePacket 11y ago
    That's a really interesting use case, thanks for mentioning it.
barrkel 11y ago
When you have lots of rows, you want to think more in terms of set operations; and when you have complex data, you'll want to structure it relationally, and then you'll have a bunch of little tables filled with ids. In this case, something tree-like would be better to follow the indirections. It's pretty rare - mostly for ad-hoc interactive debugging, typically where there's some UI missing or not yet implemented - that you'd want to edit a single row's contents.
- sandGorgon 11y ago
  actually, you were bang on the usecase ("typically where there's some UI missing or not yet implemented "), but not for debugging. In fact, if I'm not wrong there was a startup that got launched on HN or PH or somewhere that just builds database connected spreadsheet-like webapps. The thing is - in operations driven startups, the early days are built on top of spreadsheets. Which can get unmanageable within days. So then you start building your webapp. Something like dbeaver turns into a godsend because you then use the database as a spreadsheet, while you take your time building the webapp. A spreadsheet is so much more common than a webapp with an opinionated UI - it was so surprising that when I handed over dbeaver to an operations guy, he actually had zero trouble using it to do his work. In fact the UI we are building now is on top of Handsontable (a JS spreadsheet component) rather than a form-like web component. Everyone is just so used to copy pasting rows, manipulating data,etc.

I would still use dBeaver because it allows me to edit data like Excel. And the fact that it works brilliantly on Linux. I'm not sure why more db tools don't follow that paradigm.

wsh91 11y ago

Truth! Also, for its support of alternative databases like Mongo and Cassandra.

jmnicolas 11y ago

Because when you have a couple million rows in a table, you don't want to edit it à la Excel ;-)

sandGorgon 11y ago
not all kinds of editing are changing a billion rows at a time. Sometimes, you just want to change a few rows and few columns. I have actually used dbeaver as an order management system, while my front end caught up.
- PudgePacket 11y ago
  That's a really interesting use case, thanks for mentioning it.

barrkel 11y ago

When you have lots of rows, you want to think more in terms of set operations; and when you have complex data, you'll want to structure it relationally, and then you'll have a bunch of little tables filled with ids. In this case, something tree-like would be better to follow the indirections. It's pretty rare - mostly for ad-hoc interactive debugging, typically where there's some UI missing or not yet implemented - that you'd want to edit a single row's contents.

sandGorgon 11y ago
actually, you were bang on the usecase ("typically where there's some UI missing or not yet implemented "), but not for debugging. In fact, if I'm not wrong there was a startup that got launched on HN or PH or somewhere that just builds database connected spreadsheet-like webapps. The thing is - in operations driven startups, the early days are built on top of spreadsheets. Which can get unmanageable within days. So then you start building your webapp. Something like dbeaver turns into a godsend because you then use the database as a spreadsheet, while you take your time building the webapp. A spreadsheet is so much more common than a webapp with an opinionated UI - it was so surprising that when I handed over dbeaver to an operations guy, he actually had zero trouble using it to do his work. In fact the UI we are building now is on top of Handsontable (a JS spreadsheet component) rather than a form-like web component. Everyone is just so used to copy pasting rows, manipulating data,etc.