4 ms·

This reminds me of something that happened in a previous gig where our team was working primarily with SQL. The company rockstar one-day decided to rid us all o

by tjpnz 8y ago

This reminds me of something that happened in a previous gig where our team was working primarily with SQL. The company rockstar one-day decided to rid us all of our perceived misery by introducing a REST interface over our existing databases complete with it's own query language that he managed to foist upon us with the clout he had with upper management. The query language was limited at best even when compared to some of the examples in the article. Initially all it provided was basic matching against several columns and the ability to do rudimentary paging across resultsets. Naturally we had problems with this as a big part of our job was writing reports relying heavily on joins and aggregation - we were left in a situation familiar to anyone whose used NoSQL joining everything in code but without all of the niceties that come with maturity. It's a given that team productivity and general morale took a bit of a dive at this point. My current theory to the proliferation of these query languages is ignorance. Aside from a severe case of NIH the developer behind our query language exhibited a flawed understanding of SQL. If you're planning to roll your own query language you probably shouldn't without first considering SQL, your intended users and the use cases that they're trying to satisfy.

scarface74 8y ago
Initially all it provided was basic matching against several columns and the ability to do rudimentary paging across resultsets. Naturally we had problems with this as a big part of our job was writing reports relying heavily on joins and aggregation - we were left in a situation familiar to anyone whose used NoSQL joining everything in code but without all of the niceties that come with maturity. It's a given that team productivity and general morale took a bit of a dive at this point. Yes being forced to use a REST interface over reports is a bad idea but that has nothing to do with joins over a NoSQL data store. Mongo does joins via the $lookup function and the C# Mongo driver will translate the LINQ code to MongoQuery for you. https://www.axonize.com/blog/joining-collections-mongodb-using-c-driver-linq/ https://www.axonize.com/blog/joining-collections-mongodb-usi... Worse case even if you do get data sources from separate places, it’s just as easy to do joins on two lists as it is to do in Sql using LINQ.
tannhaeuser 8y ago
This sounds all too familiar. Developers having a REST epiphany and thinking they're clever by mapping relational rows to REST resources is also very common with Spring apps (Spring data in particular).

by tjpnz 8y ago

scarface74 8y ago

Initially all it provided was basic matching against several columns and the ability to do rudimentary paging across resultsets. Naturally we had problems with this as a big part of our job was writing reports relying heavily on joins and aggregation - we were left in a situation familiar to anyone whose used NoSQL joining everything in code but without all of the niceties that come with maturity. It's a given that team productivity and general morale took a bit of a dive at this point. Yes being forced to use a REST interface over reports is a bad idea but that has nothing to do with joins over a NoSQL data store. Mongo does joins via the $lookup function and the C# Mongo driver will translate the LINQ code to MongoQuery for you. https://www.axonize.com/blog/joining-collections-mongodb-using-c-driver-linq/ https://www.axonize.com/blog/joining-collections-mongodb-usi... Worse case even if you do get data sources from separate places, it’s just as easy to do joins on two lists as it is to do in Sql using LINQ.

tannhaeuser 8y ago

This sounds all too familiar. Developers having a REST epiphany and thinking they're clever by mapping relational rows to REST resources is also very common with Spring apps (Spring data in particular).