Why is database support in every language bad? | Hacker News Reader

Why is database support in every language bad?

4 pointswritten-beyond8 comments

I don't get it, no matter which language you look to or which framework or ORM you use they're all just bad.

All I care about and want to care about is knowing the type of the response I'm getting from my database call. I don't need a query builder or an ORM, it could just be something in the LSP that can tell me when I'm doing something wrong.

I've done a lot of db, (sql & no-sql) work before but I always did it on autopilot, without actually rationalizing about how terrible the experience is.

The closest thing I've gotten to something exactly that I want is SQLx in Rust which does query verification by checking against your db. It just feels like overkill to use Rust for building a simple REST CRUD app.

Every other language has some variation of code-gen with an ORM or QueryBuilder to go with it and I think that's just too complicated.

I thought SQLC in go would be better but golangs ergonomics are terrible plus I find it very hard to write my queries in a different file, then generate code and then start using it only to realize I need to change something in the query and I start the whole process over again.

NodeJS isn't any better either with Prisma, Drizzle and Kysely it's a lot of work just to get started with the tools. Figure out their respective ORM type formats, then either generate them or write them yourself. Sure you can use Knex but Knex doesn't give you any type information.

Finally if you try to go with the "battle tested" languages like Java and C# with Hibernate and Linq the amount of work you need to do to just initialize projects in those languages is a completely different headache. It's a huge time investment in laying out those projects.

Am I doing something wrong, it's not like I've never used a database before, or don't understand sql. Everything seems like it's so much work and it's exhausting to even think about.

re: > see information about sql queries from shell command line. aka nosql - oci cli [1]

Note: field orders must be same for remote odbc & local rust data.

remote odbc ordered dumping of 'sql query' in json format to file 1.

local rust ordered dumping of 'sql query' in json format to file 2.

Do a diff between file1 & file2. 'empty result', specified types match. non-empty result, then may be a more data in one file than other, type mismatches, 'name' mismatches, or something else.

sticking to the 'only use sql' theme:

Instead of file1 and file2, can dump to temporary table1 and temporary table2.

'Flatten' each individual json record before table insertion! (may need to introduce record order number as index.)

json for file1 is in single column, json for file2 is in single column. join on 'string similarities'. -- 'null values' in one field but not in another indicate unmatched pair. -- may be data type or 'value type', requiring additional sql query to get at needed data type mismatch.

Relational databases model data relations (...) and that doesn't really fit a programming languages or, generally, the real world. SQL fits, so it's just easier to use either that or a dsl that follows it more or less exactly so you don't have this mismatch. I find some of the most silly ones prisma/drizzle while EF/Linq works quite well (not sure what you mean amount of work to initialise projects? It's not more than some node express thing these days?) for something that's not a direct mapping. Datalog, prql are also things that work well for me, but usually we usually just use sql directly.

Like I mentioned, I prefer using SQL directly. I just want some type safety on the result of my query. Is it going to be a list of rows, is it going to be a single row, what will the columns be named exactly, will I have to convert the resulting column value to my specified type.

Those are just a lot of steps

see information about sql queries from shell command line. aka nosql - oci cli [1]

database schema data can be queried to find the table(s) field name & table(s) type. That is an additional separate sql query though & would potentially be different for different databases & database versions.

ODBC protocol was designed to address the 'different database schema formats' issues via a 'universal database access' interface. (vs. jdbc, java language equivalent of odbc)[2].

The command line program, usql[3] provides support for sql querying different databases.

Setting sql query to output query results in json format would provide relevant information such as field name & data type within the sql output data. note: sql allows for renaming table names within the sql query. aka select tablea.first_name as surname

----

[1] : http://docs.oracle.com/en-us/iaas/tools/oci-cli/3.51.9/oci_c...

[2] : https://en.wikipedia.org/wiki/Open_Database_Connectivity

[3] : https://github.com/xo/usql

EF Core is excellent and is among the least ceremonious ORM frameworks with the ability to easily drop-down to type-safe and injection-safe interpolated SQL (https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...).

Frameworks / ORM are just specilized database user interface front ends designed to simplify how data can be used (displayed/inputted/manipulated). They can also display known databases/table, such that the user just has to select what's needed (or doesn't have to worry about tables/field -- just the display/forms to get results.

Database management systems usually provide a way of importing/exporting 'raw' data via sql statement(s) results. aka cvs, comma delimited, html formatted, json formatted.

Outside of a framework/ORM from command line / operating system shell; can do a command line sql query with 'html formatted output' and open results of file in a brower. Obvious catch of not using 'tools/environment' is gotta do all the data input cleanup/checks; output formatting for display/printing, such as only want 4 lines of output per printed page. Note: will have to provide database(s) to access information from via databases specific method!

example programs that provide access to sql via command line:

   postgres psql provides an interactive 'cli' environment for using sql 

   windows sql server - sqlcmd;

   usql[1] provides something similar to psql for no-sql databases.

---

sqlc is sorta the equivalent of combining the command line shell & sql queries. The 'c' portion of sql, is c language. So, outside of sql, on own to write what ever 'shell' functionality needed using c.

SQLx rust is rust extention for handling 'sql from command line, just via rust language, instead of going through command line shell.' except, rust language also handles the internet protocols/language extentions for doing rest crud / sql / rust in a single app.

There are program(s) usable from a command line shell (cli) that would provide 'rest crud'.

Different levels of packaging provide differing levels of control/amount of hoops have to jump through. (just raw data, data & usage, just usage)

Unlike databases, spreadsheets provide an interactive gui up front, with 'embedded language' providing the 'data manipulations' aka visual, python, etc. spreadsheet data can be retreived from / sent to a database.

----

[1] : https://github.com/xo/usql

https://blog.codinghorror.com/object-relational-mapping-is-t...

The relational algebra is a line encoding. When you put bits on a wire (or a magnetic surface), they're not the same bits; there are more of them, for at least two different reasons, and they have to be translated in both directions. But you only want to see your bits. Similarly, programming languages only want to see their data structures, but The Database can only deal with the relational algebra, which is like a wire not being able to transmit more than three consecutive zero bits, and the translations are arbitrarily complex. The difference is that wires and disks don't have administrators who demand that everyone must think exclusively in terms of the line encoding.

Reply on news.ycombinator.com