So as I got to work on this, I started keeping notes. I knew there were some things Postgres did that My SQL didn't, but I also knew there were a ton of things I'd just never tried in the latter. Not good, was the obvious answer, but less immediately obvious was how not good. ![]() Anyway: things happen, and sometimes you find yourself having to answer the question "what's it going to look like if we need to run these applications with light but tightly coupled data layers on My SQL?" This is, ideally, something you know about up front. Where Massive is less useful is if you have to support another RDBMS. you write SQL, you store it in one central place for reuse, and the API makes running it simple. It's great for getting things done, since the basics are easy and for the complicated stuff where you'd be writing SQL anyway. Specializing lets it take advantage of features which only exist in some or no other relational databases to streamline data access in a lighter, more "JavaScripty" way than a more traditional object-relational mapper. Massive is closely coupled to Postgres by design. ![]() ![]() The scenario: two applications, using Massive.js to store and retrieve data. This is not an unbiased comparison - but those are no fun anyway. I should probably say up front that I love working with Postgres and could die happy without ever seeing a mysql> prompt again.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |