9 ms·

I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. While scaling is one of the advantages, I'd be su

• matwood 8y ago
  > Microsoft at one stage had Linq to SQL which was quite good..... but they killed it :) They also had a rest API directly into the db server at one point, but killed that also.
• sidstling 8y ago
  Linq to SQL is still a thing, you may need to click it’s package when you install visual studio 2017+, but it’s still there and it’s still the best SQL interface they have build in my opinion. We rarely use anything else, but I can see the value of entity if you’re changing your DB a lot. We typically don’t do that though, and to be honest, working with changes with linq to sql, typically goes smoother than entity migrations. Disclaimer: it’s entirely possible that we simply suck at entity.
  • pbz 8y ago
    LINQ to SQL is a dead end. Look into LINQ to DB https://github.com/linq2db/linq2db https://github.com/linq2db/linq2db which is way faster than LINQ to SQL ever was (faster than even Dapper). If you must you could give EF a try, but stay away from LINQ to SQL.
    • CuriousSkeptic 8y ago
      The value of Dapper IMHO is not the speed. It is precisely the interface. With dapper I can copy paste code between C# and SQL contexts freely. Exploring the database directly in SQL and then use the result directly in the program without a translation step.
    • naasking 8y ago
      LINQ to DB has always seemed interesting, but I don't like it's use of attributes for POCO properties. It's not clear from the introduction whether non-attribute properties will work if the names and types are compatible, or even if the attributes are custom or come from the standard System.ComponentModel.DataAnnotations. The attributes aren't discussed at all in the introductory examples actually.
• 189723954 8y ago
  >I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. I chose Mongo for a project recently. I have many years experience with SQL databases, and I think SQL will become more of a niche in the future. Here are the reasons: Everybody uses an ORM with a SQL database. You can pretend they don't and everyone is writing raw sql, but they aren't. This is basically a big, complicated, and slow piece of software that tries to make a SQL database into something else. A NoSQL database is like a native version of that. It starts off with you being able to define collections and schemas in code and so on. SQL is a shit way to query a database. I used to write massive queries that took an hour or so to write just so that the non-programming people could put them into analytics software that didn't support any other methods of input. While I was writing these queries, I was just thinking to myself "I can write this in code in a few minutes instead of an hour or more". The fact is that programming languages are much better at querying databases than SQL. Joins are slow and complicated, and ORMs are slow and complicated, so you can never actually use any of these things in a high-traffic environment. As you say, not many people will reach these levels of traffic, but it is still a factor. Most of the comments about "I moved from mongo to postgres" lately are first-time programmers who didn't know any of the basic concepts of databases. They then discovered patterns that the SQL database forced on them and declared that mongo sucks when in reality, they just didn't know what they were doing. >One of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database. This is not true at all. Programming languages are vastly superior at querying a database. Just go write a complex query and compare it to the one in linq or whatever you use. >Microsoft at one stage had Linq to SQL which was quite good..... but they killed it :) They have entity framework, which uses linq and is the same thing. It is very slow though.
  • richmarr 8y ago
    > This is basically a big, complicated, and slow piece of software that tries to make a SQL database into something else. Just to nitpick a little, but I think it's a worthwhile distinction, ORMs don't try to make a SQL database something else... either literally or philosophically. To use them in any more than a trivial way you still to understand RDBMSs. They just make the queries less verbose and the output more convenient to work with.
• Sjenk 8y ago
  Not only easy in Javascript, it is easy in any language that has easy serliazation to JSON. I always use it for my own hobby projects because I dont have that much SQL knowledge. Which makes Nosql easy choice for me, just serialize your object into json and push it to your DB.
  • lotsofcows 8y ago
    That's not a choice. To make a choice you need to be aware of alternatives. You use NOSQL because it was easy to achieve your goal.
    • Sjenk 8y ago
      Dont mean to troll. But how choosing for the easiest way to achieve your goal not a choice?
      • lotsofcows 8y ago
        That's a different choice. You might be "choosing" not to bother understanding the alternatives, but you're not making a choice between the alternatives because you don't know what they are.
  • ben509 8y ago
    Pushing a serialized object into a distributed hash definitely solves some problems. And you have finite time, so if the choice is between that solution that you can do now and searching for another solution that may or may not be better, it's often reasonable to go with the known solution. In economics, this is known as "rational ignorance." The value proposition of learning will change, though. You will find it's worth it, especially if you move beyond hobby projects and have to deal with any kind of business logic, to spend some time learning how databases work, and maybe even the math behind them, the relational model. There are a lot of mediocre or awful references out there. If you need a good text on the subject, I recommend CJ Date's "Introduction to Database Systems." Note, though, I said good, not easy.
• sametmax 8y ago
  > it is super easy to program with javascript. It would be more honest to say that the weird js design, its lack of features and ridiculously small stdlib made it harder to do anything complicated at the time (no ES6 or webpack, remember ?). Hence, not good tooling existed for relational databases: no decent abstraction layer, migration lib or ORM. Lost of languages had a 2 liner to pop an sqlite db without needing to install anything, but JS didn't even have that. So here you are, with thousands of front end devs that were just learning to declare their variable correctly, coming to the server. They had the choice between a technology that needed a lot of boiler plate to get anything done, and provided a painful experience with many early errors. Or something that just seemed to work out of the box. You just dump your thoughts in it. You don't need to think. No error back. It just says "ok". Seemed is, however, important here. The first years of mongo, it failed miserably, but you only saw it down the road of the projects using it. And of course the inexperience of the css wizards using it as a "dump-my-data" store prove to be a terrible curse. At the time, if you said any of those things, people would have called you an old grumpy looser that didn't want to live in the future. But they learned that, just like "var" was important to avoid bugs instead of using your variable whenever you felt like it, deciding of a formal schema was, even for document data store, an important thing to do. Fast forward, the JS community has now matured and include modern constructs, a rich ecosystem and people with way more experience. Mongo has changed its design and has now sweet spots use cases. But we still don't have good tooling for relational DB in JS. And it's still important to have an explicit document stating which schema you use for your document store. Schema less means you can do whatever you want. It doesn't mean, however, that you should.
  • kapv89 8y ago
    True that Node.JS didn't have, and still doesn't have a 2 liner to pop an sqlite db. But what it did have(a few years after its launch) was a pure-JS sqlite client which can leverage V8's event loop and libuv to make parallel execution of db-queries a trivial operation. There is a lot of mettle in Node.js for server side programming. PS: have you looked at TypeORM(http://typeorm.io/ http://typeorm.io/)
    • sametmax 8y ago
• mpweiher 8y ago
  > kicking out as many layers between a relational db and a REST Api Cool, is there anything we can see? I pretty much stumbled upon something along those lines back in 2003, and developed it into what I now call "In-Process REST"[1][2] and "Polymorphic Identifiers"[3][4]. The idea being that you can stay within a "storage-oriented vocabulary" for as much as possible, and that can include seamlessly all the way from provided interface to various storage mechanisms. What's neat is that it reduces friction a lot, greatly enhances composability and reusability and just makes things blatantly obvious. [1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_11 https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_... [2] https://github.com/mpw/SoftArchLon2016-In-Process-REST/blob/master/In-Process-REST.pdf https://github.com/mpw/SoftArchLon2016-In-Process-REST/blob/... [3] https://www.hpi.uni-potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf https://www.hpi.uni-potsdam.de/hirschfeld/publications/media... [4] http://objective.st/URIs/ http://objective.st/URIs/
• ElectronShak 8y ago
  > The REAL problem SQL wrappers need to solve is that most languages don't have a good interface with SQL. So most often SQL is handled in strings and manipulated with string manipulation and there is no type safe way transitioning data from the DB to a general purpose language. For me this is (was) the main problem. When building Android apps and there was need to store some data locally, I always used Realm (https://realm.io/blog/realm-for-android/ https://realm.io/blog/realm-for-android/) because their API was way easier to use, other than the default SQLite database. Of course this made the apk significantly big, but at least i knew how to manage the data. SQLite on the other hand, wasn't easy to work with, and worse when it came to versioning / updating the local database schema / definition without messing things. I say (was) because late last year, I started using Room (https://developer.android.com/topic/libraries/architecture/room https://developer.android.com/topic/libraries/architecture/r...), and working with SQLite on Android has never been way easier. So yes, this has been a problem, but the solutions if built well, are great.
• infinite8s 8y ago
  This is similar to the problem of macro programming by eval'ing a string (in dynamic languages). Basically you are trying to construct a tree (AST) by glueing together linear strings of text (instead of working natively with trees)
• _Codemonkeyism 8y ago
  Same here, using Mongo helped us a lot to iterate fast, JSON is much more agile than SQL. We now migrate to PG using 'core' attributes in tables and 'flexible' attributes in JSONB to get the best of two worlds. I agree to the API problem, JDBC and PG/SQL is not as nice as a interace compared to Mongo libs.
  • sytse 8y ago
    When you say JSON is more agile is that because you don't need to write migrations? Do you use a framework that supports migrations like active record or south?
    • collyw 8y ago
      Writing a load of consistency checks in the application layer sounds the opposite of agile to me. Unless you just want sloppy data.
    • _Codemonkeyism 8y ago
      We do not use migrations with JSON. Adding and removing happens on the application layer with using Option[_] monads in the data model. Add a field means add Option[_], removing a field means making e.g. String an Option[String] - or fill with default values on read. If we drop a field over time we ignore it during writes. case class Person(name:String) adding a job field after some time becomes case class Person(name:String, job:Option[String]) and application code needs to deal with it. Works for us, compared to my previous jobs where we used SQL and migrations.
• uptownJimmy 8y ago
  Dapper is a great tool for getting an app started and up to speed, and even later once the app gets bigger if sometimes it makes sense to bypass the ORM and hit the DB straight-on.
• ben509 8y ago
  > I think NoSql, especially things like Mongo, got popular because it is super easy to program with javascript. NoSQL caught on because of what it doesn't do: attempt to implement the relational model. A lot of people were using MySQL in infamous LAMP stacks to set up websites with virtually no business logic. So you had: 1. An application that didn't need the relational model 2. A DBMS that had a very poor implementation of SQL, which itself is a poor implementation of the relational model 3. A large community who didn't know anything about database theory. When you're using MySQL as a glorified hashtable, you get none of the benefits of the relational model, and all the downsides. From their understanding of the technology, throwing all that out made a lot of sense. It's pretty reasonable to use a distributed hashtable if what you want is a distributed hashtable. I think the backlash now is that NoSQL marketed themselves as a capable alternative to SQL DBMSs. But they had no query optimizer, no transaction support, no reliable backups, and no schemas. The last was supposedly a selling point, but the reality is that your data always has a schema, and code will crash if the data doesn't match it. Great marketing, but people were sold half a car and then told building the rest themselves was a feature. > One of the problems of many stacks is that the frameworks wrap general purpose languages over SQL, which, is not really a good idea, SQL is a vastly more capable language for dealing with relational data and layers built over the top often dumb down the database. Another problem is that object-orientation is fairly broken, and ORMs tried to figure out how to shoehorn relational databases into inheritance hierarchies. If current notions like value classes had been around, a more straightforward mapping would have been possible.
  • d4l3k 8y ago
    MongoDB certainly was missing a lot of things when they first launched and were very hyped, but now pretty much everything you could want in a database is now in MongoDB. Multi-document transactions + strong consistency: https://docs.mongodb.com/manual/core/write-operations-atomicity/ https://docs.mongodb.com/manual/core/write-operations-atomic... Passes Jepsen test: https://www.mongodb.com/mongodb-3.4-passes-jepsen-test https://www.mongodb.com/mongodb-3.4-passes-jepsen-test Schema: https://docs.mongodb.com/manual/core/schema-validation/ https://docs.mongodb.com/manual/core/schema-validation/ Query Optimizer: https://docs.mongodb.com/manual/core/query-plans/ https://docs.mongodb.com/manual/core/query-plans/ Backups: https://docs.mongodb.com/manual/core/backups/ https://docs.mongodb.com/manual/core/backups/
• bunderbunder 8y ago
  > Microsoft at one stage had Linq to SQL which was quite good..... but they killed it :) I think that might be like when rock stars die at 26 instead of hanging around long enough to become the subject of a VH1 "Where are they Now?" episode. I was on a project that used LINQ to SQL long after Microsoft stopped development on it, and consequently fell out of love with it. The caching mechanism was flaky, and could cause really weird problems that manifested in non-obvious ways. Also, changing the database schema in a LINQ to SQL project could be a chore. I ended up migrating us away from it and toward Dapper. We ended up bypassing it way too often to be able to straight-facedly claim it was saving us from having to understand SQL (if that was ever possible), It was the warts, but even more than that, it was the many situations where, to get the query right, we needed to use a recursive CTE, or a temp table, or a table-valued parameter, or any of the oodles of other things that are awkward or impossible with an ORM.
  • soundwave106 8y ago
    Dapper is great IMHO. However, the Microsoft-recommended solution after Linq to SQL ended up being Entity Framework... which was an even heavier ORM. My personal opinion is akin to the parent: the more you abstract away from thinking like your data store, the easier it is to write poorly performing code, because some of the fundamentals get lost in the process. For instance, in EF and other ORMs, one classic pitfall is "N+1" queries. Even though it's a well known issue to avoid, I still run into poorly performing loops quite often. Here, I feel the abstraction is partially responsible. Most for loops run in code (in memory at least) very quickly, even against a lot of records. However, those who develop against SQL know that you avoid cursors etc. as much as possible, and that for loops / cursors against a SQL database will bite you the instance you are dealing with thousands of records to loop through. I don't think it's always "obvious" to, say, a relatively new C# developer with less experience writing SQL, that this for loop against a SQL database is going to literally translate into thousands of select statements that will perform poorly. I think it's possible to use a heavy ORM like Entity Framework and write well performing code, but there has to be some awareness of when the task is too complex for the ORM to perform well, and you need to switch to a stored procedure. And there has to be at least a little bit of understanding on how to write well performing interactions with the DB.
• spikej 8y ago
  Its been mentioned here before, but check out Rezoom.SQL https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL All the power with static typing