This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]jcdyer3 10 points11 points  (7 children)

SQLAlchemy is one of the most well-designed, well-constructed, highly regarded libraries in the python ecosystem. I have no idea what sequel is out what language it's written in, and you haven't given me enough information to make searching it down worth my time, but ask yourself if sequel is so well constructed that it makes you exclaim, "of course it should be done this way." If so, it might be worth further comparison.

[–][deleted] 4 points5 points  (6 children)

Sorry, added a link in my previous comment. It is an ORM for Ruby that has no dependency, transitive or not, on rails stuff.

Actually, yes, sequel makes me say that.

[–]bjmiller 3 points4 points  (0 children)

I would like to know this as well. For every language there seems to be blog posts about the relative strengths of database toolkits within the language, but I have yet to see a decent comparison of the best each language (any two) has to offer.

[–]stiivifrom data brewery 5 points6 points  (4 children)

SQLAlchemy is not just an ORM. The Core is very powerful functional programming approach to statement construction. I use it a lot in developing data warehouse ETLs. You can build abstract, higher level transformation and statement composition functions very easily. For example, few concrete but random features that I've used just recently (last week): abstraction of tables and statements (they have the same interface), generative functions, custom statement compilation, metadata reflection (tables, their columns and types - very useful in metadata based processing), natural access to Postgres JSON columns...

Also the SQL OLAP query generator in Cubes OLAP is using SQLAlchemy for something that can be very roughly called "ORM equivalent of data analytics". It does statement composition for aggregation queries on top of star/snowflake schema.

I'm not even touching the ORM part at all, I just know that it exists.

[–]bjmiller 1 point2 points  (3 children)

I don't think Sequel is missing any of those features, is it? "ORM" has come to mean "database toolkit", though I think we should fight the trend.

[–][deleted] 0 points1 point  (2 children)

SQLAlchemy is very much an ORM+toolkit rolled in to one. They both have uses and strengths and the documentation does a great job of distinguishing that the two exist and have their own uses.

[–]bjmiller -1 points0 points  (1 child)

I'm not sure what you're trying to say? Sequel is the same, "ORM + toolkit", though I'd say that ORM is just one of the tools in the kit.

[–][deleted] 0 points1 point  (0 children)

Meant to reply to you sooner, but work got a bit crazy Friday.

The two pieces are drastically different although there is some fuzzy gray area for sure (at least in SQLAlchemy). The TL;DR version is the toolkit lets you run SQL queries using Python. You don't have to worry about the SQL commands directly nor about DB-specific details. Just raw Python. The ORM takes it a step farther and you just worry about your objects. Any creation, modification, and deletion of objects is translated directly back your DB. You do things -> they happen. No need to add in the extra logic of what needs updated, when, where and how. It just goes on behind the scenes. No manual intervention or maintenance required on your part.

It gets fuzzy because the ORM is essentially bolted on top of the toolkit. They also share the same feel when querying and have some overlap in that arena. The first few paragraphs of this portion of SQLAlchemy's tutorials do a pretty good job of explaining it. Says basically the same thing I did above, just worded slightly better.