4 ms·

It's nothing even remotely like JSON. It doesn't encode the same information or semantics at all. Your entire argument is "old stuff is bad and I like JSON".

It's nothing even remotely like JSON. It doesn't encode the same information or semantics at all. Your entire argument is "old stuff is bad and I like JSON". And yes we should use XML. At least it has competent, verifiable, consistent schemas and contracts. At the very least, you can encode xs:decimal in it unlike JSON which is "oh it's some shit that looks like a number and we might stick in a double at the other end because we don't know our butt from our elbow". I ask you with JSON, how do you encode "add a single item to the list attached to a customer" I am so so so tired of dealing with this level of thinking on a daily basis.

josephg 2y ago
I must admit, I'm having more of a go at SQL than I really feel. SQL nailed transactional semantics, indexes and querying. My argument isn't that "old stuff is bad and I like JSON". Its that when I'm modelling data in my program, sometimes I have objects which reference each other (via key or shared pointer). And sometimes I have objects which contain another object. Eg, a struct with a vec inside. Real code is packed full of this stuff. SQL lets me directly model relationships between objects. And it lets me model records with scalar fields. But it does not let me model records with variable size fields. This restriction seems totally arbitrary. There is no technical reason for it that I can think of. And it makes it needlessly complex to map data from my programming language to my SQL database. I've named this problem 3 times in this thread now. For all your moaning about us kids being lazy, you still haven't given a single technical reason for this deficiency in SQL. I largely agree with you about JSON. I don't actually want JSON fields in my database. I want something strongly typed, with well defined semantics and a good query system. SQL has a great track record of providing just that. And it has a perfectly serviceable type system already. So why on earth is it missing this important, obvious feature? I just want my database to be able to express embedded lists and records, like I do in almost every programming language I've ever used, every messaging format I've used (protobuf, msgpack, json, xml, etc). And in many other databases (couchdb, mongo, foundationdb, etc). > I ask you with JSON, how do you encode "add a single item to the list attached to a customer" I can think of dozens of ways to express that. Postgres already supports that operation for embedded JSON fields using this ugly syntax: UPDATE <table> SET <field-name> = <field-name> || '{"a": 1}'::jsonb Mongodb expresses it like this: { $push: { <field1>: <value1>, ... } } Rethinkdb: r.table('marvel').get('IronMan')('equipment').append('newBoots').run(conn, callback) ... Do you need more examples? Basically every database natively supports this except for "raw" SQL databases. Edit: Apparently (according to other comments in this thread) some SQL databases are already moving in this direction anyway. How wonderful!
- consteval 2y ago
  > But it does not let me model records with variable size fields. This restriction seems totally arbitrary Yes it does. Customers have orders which are an array. You have two tables then CUSTOMER and ORDER and you JOIN them. Why not just put the orders inside of CUSTOMER? Because now you can't query it, because you don't know how many columns will come out and you can't have disparate columns across rows. So maybe you dump it all in one column, but obviously that has problem in terms of forming relations. Sure, it's a different way of thinking. But its faster, its MUCH safer, the invariants are actually properly specified. Sure you can use mongodb and that will work for wild-westing your way through software. But I wouldn't dare touch a mongo instance without going through the application, because all the constraints are willy-nilly implicitly applied in the application. But I directly view and edit SQL databases daily.
  - josephg 2y ago
    > You have two tables then CUSTOMER and ORDER and you JOIN them. Why not just put the orders inside of CUSTOMER? Because now you can't query it, because you don't know how many columns will come out and you can't have disparate columns across rows. Why wouldn't you be able to query it? You can query JSON fields that contain lists. Why not SQL fields with strongly typed lists? > Sure, it's a different way of thinking. But its faster, its MUCH safer, the invariants are actually properly specified. Why would it be safer? An embedded list has pretty clear and obvious semantics. And as ekimekim said in another comment, postgres already has partial support. Apparently this works today: CREATE TABLE example ( height number_with_unit, -- our composite type, eg. (6, 'ft') or (180, 'cm') known_aliases TEXT[], -- list of string active_times TSRANGE, -- time range, ie. (start, end) timestamp pair ); An embedded list also sounds much faster to me - because you don't have to JOIN. Embedding a list promises to the database "I'll always fetch this content in the context of the containing record". Instead of (fetch row) -> (fetch referencing key) -> (fetch rows in child table), the database can simply fetch the associated field directly. > But I wouldn't dare touch a mongo instance without going through the application, because all the constraints are willy-nilly implicitly applied in the application. Yes, I hate mongodb as much as you do. I want explicit types and explicit invariants. But right now mongodb has useful features that are missing / unloved in SQL. How embarrassing. SQL databases should just add support for this approach to data modelling. Its nice to see that postgres is trying exactly that. In programming, I don't have to choose between javascript and assembly. I have nice languages like rust with good type systems and good performance. We can have nice things.

josephg 2y ago

I must admit, I'm having more of a go at SQL than I really feel. SQL nailed transactional semantics, indexes and querying. My argument isn't that "old stuff is bad and I like JSON". Its that when I'm modelling data in my program, sometimes I have objects which reference each other (via key or shared pointer). And sometimes I have objects which contain another object. Eg, a struct with a vec inside. Real code is packed full of this stuff. SQL lets me directly model relationships between objects. And it lets me model records with scalar fields. But it does not let me model records with variable size fields. This restriction seems totally arbitrary. There is no technical reason for it that I can think of. And it makes it needlessly complex to map data from my programming language to my SQL database. I've named this problem 3 times in this thread now. For all your moaning about us kids being lazy, you still haven't given a single technical reason for this deficiency in SQL. I largely agree with you about JSON. I don't actually want JSON fields in my database. I want something strongly typed, with well defined semantics and a good query system. SQL has a great track record of providing just that. And it has a perfectly serviceable type system already. So why on earth is it missing this important, obvious feature? I just want my database to be able to express embedded lists and records, like I do in almost every programming language I've ever used, every messaging format I've used (protobuf, msgpack, json, xml, etc). And in many other databases (couchdb, mongo, foundationdb, etc). > I ask you with JSON, how do you encode "add a single item to the list attached to a customer" I can think of dozens of ways to express that. Postgres already supports that operation for embedded JSON fields using this ugly syntax: UPDATE <table> SET <field-name> = <field-name> || '{"a": 1}'::jsonb Mongodb expresses it like this: { $push: { <field1>: <value1>, ... } } Rethinkdb: r.table('marvel').get('IronMan')('equipment').append('newBoots').run(conn, callback) ... Do you need more examples? Basically every database natively supports this except for "raw" SQL databases. Edit: Apparently (according to other comments in this thread) some SQL databases are already moving in this direction anyway. How wonderful!

consteval 2y ago
> But it does not let me model records with variable size fields. This restriction seems totally arbitrary Yes it does. Customers have orders which are an array. You have two tables then CUSTOMER and ORDER and you JOIN them. Why not just put the orders inside of CUSTOMER? Because now you can't query it, because you don't know how many columns will come out and you can't have disparate columns across rows. So maybe you dump it all in one column, but obviously that has problem in terms of forming relations. Sure, it's a different way of thinking. But its faster, its MUCH safer, the invariants are actually properly specified. Sure you can use mongodb and that will work for wild-westing your way through software. But I wouldn't dare touch a mongo instance without going through the application, because all the constraints are willy-nilly implicitly applied in the application. But I directly view and edit SQL databases daily.
- josephg 2y ago
  > You have two tables then CUSTOMER and ORDER and you JOIN them. Why not just put the orders inside of CUSTOMER? Because now you can't query it, because you don't know how many columns will come out and you can't have disparate columns across rows. Why wouldn't you be able to query it? You can query JSON fields that contain lists. Why not SQL fields with strongly typed lists? > Sure, it's a different way of thinking. But its faster, its MUCH safer, the invariants are actually properly specified. Why would it be safer? An embedded list has pretty clear and obvious semantics. And as ekimekim said in another comment, postgres already has partial support. Apparently this works today: CREATE TABLE example ( height number_with_unit, -- our composite type, eg. (6, 'ft') or (180, 'cm') known_aliases TEXT[], -- list of string active_times TSRANGE, -- time range, ie. (start, end) timestamp pair ); An embedded list also sounds much faster to me - because you don't have to JOIN. Embedding a list promises to the database "I'll always fetch this content in the context of the containing record". Instead of (fetch row) -> (fetch referencing key) -> (fetch rows in child table), the database can simply fetch the associated field directly. > But I wouldn't dare touch a mongo instance without going through the application, because all the constraints are willy-nilly implicitly applied in the application. Yes, I hate mongodb as much as you do. I want explicit types and explicit invariants. But right now mongodb has useful features that are missing / unloved in SQL. How embarrassing. SQL databases should just add support for this approach to data modelling. Its nice to see that postgres is trying exactly that. In programming, I don't have to choose between javascript and assembly. I have nice languages like rust with good type systems and good performance. We can have nice things.