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

Ideas to improve the user and developer experiences of databases

dnlhg.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Ideas to improve the user and developer experiences of databases

#11

Post by avereveard »

willvarfar wrote: post #5

The main thrust seems to be tooling in the db to give developers some idea of the performance impact of the code they write. But most programmers are using frameworks and ORMs and things that hide away what is actually happening with the database. A normal developer can look at a chunk of code on their side and have no real idea of what is happening on the database behind them. What webdevelopers need is backend prof…

what we need is to kill ORM stile framework (think hybernate) and move the world toward mapper style frameworks (think mybatis)

sure, inserts are slightly more inconvenient. but the clarity and performance control on reads unparalleled.

Re: Ideas to improve the user and developer experiences of databases

#12

Post by thrower123 »

syastrov wrote: post #6

I’d like a tool that automatically suggests which indexes to add/remove, including use of different types of indexes and partial indexes, based on the queries being performed. Even better if it can automatically test the results of that on a production workload. Or suggest schema changes that would improve normalization or performance.

The Azure SQL database services are pretty nifty in this regard.

Re: Ideas to improve the user and developer experiences of databases

#13

Post by tpetry »

willvarfar wrote: post #5

The main thrust seems to be tooling in the db to give developers some idea of the performance impact of the code they write. But most programmers are using frameworks and ORMs and things that hide away what is actually happening with the database. A normal developer can look at a chunk of code on their side and have no real idea of what is happening on the database behind them. What webdevelopers need is backend prof…

You could easily instruct the orm to add a comment in front of the sql query so the database can profiling of a complete http request and show you all the bad things your orm is doing.

Something like: /* dbxperience:request=9a7cd2a6 */ SELECT ....

I have not tested it, but this is something google cloud sql recently promoted: https://cloud.google.com/blog/products/databases/get-ahead-o...

Re: Ideas to improve the user and developer experiences of databases

#16

Post by planxty »

This author is spot on.

Raise your hand if you've committed the PostgreSQL to memory for looking at the DDL for a table, or identifying slow queries. Too many database management operations require highly specialized knowledge about a given database's internals.

Folks are far too willing to spend huge money on expensive licenses for db analytics tools to tell them when queries are slow or suboptimal.

Love the idea of making the db responsible for migrations. Downside there could be that db lock-in becomes a concern, and it might add cognitive overhead connecting application code to the current schema. How do you know if app code is up to date with the db without a live connection to prod?

Re: Ideas to improve the user and developer experiences of databases

#18

Post by kristiandupont »

syastrov wrote: post #6

I’d like a tool that automatically suggests which indexes to add/remove, including use of different types of indexes and partial indexes, based on the queries being performed. Even better if it can automatically test the results of that on a production workload. Or suggest schema changes that would improve normalization or performance.

I wrote a "linter" for database (postgres) schemas. It doesn't currently say anything about indices but I am looking into that because that seems like something that you could make qualified guesses about.

[link redacted]

Re: Ideas to improve the user and developer experiences of databases

#20

Post by sokoloff »

planxty wrote: post #16

This author is spot on. Raise your hand if you've committed the PostgreSQL to memory for looking at the DDL for a table, or identifying slow queries. Too many database management operations require highly specialized knowledge about a given database's internals. Folks are far too willing to spend huge money on expensive licenses for db analytics tools to tell them when queries are slow or suboptimal. Love the idea of…

Why would I want to have the examine DDL or slow query query committed to memory? I need to know that the concept exists and I can google the syntax in 90 seconds. I’m never within 90 seconds of disaster avertable with this knowledge.
Post reply on HN