On Sep 21, 2011, at 1:46 AM, RedBaron wrote: > Hi, > I am a newbie to SQLAlchemy. While reading the docs on the sqlalchemy > site, I was a bit confused about ORM and Core. > From what I understand, we can define table and class mapping either > through ORM (defining a class that extends Base and so on) or we can > directly use Core components (Define Table's using SQL expression and > then define explicit mappings to python classes).
class mapping is only in the ORM. the table definition is in fact always based on a Core construct, the ORM just maps your class onto that table def, where Declarative provides a more succinct syntax. > In my project, I need to define mappings for tables with composite > primary/foreign keys. I was wondering which of the two approaches will > be better (easier?). it sort of depends on where you're coming from. If you're a DB purist you'd probably find it much easier to work with the Core, for starters. The ORM has more of a conceptual leap involved, so it depends on how willing you are to do things in a certain way (the ORM has more of an opinion basically). > Given that size of DB is huge (a few mega bytes > per day), which approach has a performance incentive? This question comes up a lot, but the funny thing is that the size of the database is not much of a factor, its how many rows of data you need to be moving along that impacts performance. Both the ORM and the Core are going to issue the same kinds of SELECT constructs and such. Core is going to be able to pull rows down extremely quickly compared to the ORM since it doesn't need to do much else with them, whereas the ORM needs to constantly be concerned with how rows coming in and going out are organized with respect to the Python objects they represent - if you measure this overhead in a direct matchup to the Core, it will seem very significant, because it is. But even with all of that, an ORM app can potentially perform extremely well because you're building on an approach that can be more savvy about when to select data and when not to, and the ORM has some patterns to work with second level caches as well. All of this can be built with the Core too but the extra work there is that you're working with more rudimental components. The ORM is really mostly about reducing the amount of ad-hoc code it takes to accomplish something. A more complex schema is probably easier to work with when the ORM is in use as a lot of the complexity will be handled. > Also which of > the two approaches would be easier to integrate with web development > frameworks (Grok, Pyramid etc)? the ORM is usually easier because that's what most people use and it presents an existing structure that corresponds nicely to a web request, the Session. Of course even with the Session you can send any core selectable unit to it right through execute() so the line between ORM and Core is very fluid. So the ORM is usually where people start since it doesn't prevent you from doing things in a "Core" style as needed. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
