Inheritance is more commonly thought of as an attribute of object-oriented programming languages rather than databases, but Postgres is technically an ORDBMS or object-relational database management system. My SQL, besides the inter-database query support mentioned above, has nothing. Oracle and SQL Server both have some functionality for registering external data sources, but Postgres' offering is the most extensible I'm aware of. You don't even need to know C to write a new FDW when Multicorn lets you do it in Python! It's a powerful enough feature that No SQL stalwart MongoDB sneakily built their BI Connector on top of Postgres with foreign data wrappers. You can create a "foreign table" in a Postgres database and SELECT or JOIN it like any other table - only under the hood, it's actually reading a CSV, talking to another DBMS, or even querying a REST API. Foreign Data Wrappersįoreign data wrappers let Postgres talk to practically anything that represents information as discrete records. With Postgres, you can work across schemas, but if you need to query information in a different database, that's a job for. My SQL's simplicity in this respect is ameliorated by its offering cross-database queries: SELECT * For Postgres, a "schema" is a namespace within a database, which allows you to group tables, views, and functions together without having to break them apart into different databases. To My SQL, "schema" is synonymous with "database". Multiple Schemasįirst things first: "schema" doesn't always mean the same thing. But there's a lot of room for variation within that theme. Postgres and My SQL are both relational databases, grouping records in strictly-defined tables. Now that we're all basically over the collective hallucination of a "schemaless" future, arguably the most important aspect of data storage is how information is modeled in a database. 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 |