tag:blogger.com,1999:blog-684183198890094283.post6701130741472856710..comments2023-11-05T06:12:59.718-05:00Comments on S.Lott-Software Architect: Object Models and Relational Joins -- Endless ConfusionS.Lotthttp://www.blogger.com/profile/06337323642834330176noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-684183198890094283.post-69915441706170705822009-08-01T21:08:35.454-04:002009-08-01T21:08:35.454-04:00fumanchu: yes, we're doing that on a project ...fumanchu: yes, we're doing that on a project now (sorta). lucene is basically a way of providing views. we still use SQL all over the place though for smaller ad-hoc result sets.<br /><br />infixum: SQL being obviated by ORMs is not how we all look at it.mike bayerhttps://www.blogger.com/profile/01417862951114999907noreply@blogger.comtag:blogger.com,1999:blog-684183198890094283.post-64548484120740998902009-07-31T13:29:02.016-04:002009-07-31T13:29:02.016-04:00I attended a Django tutorial and was blown away by...I attended a Django tutorial and was blown away by the idea that SQL really isn't a factor, even though you're using data from a database.<br />For 10 years, my whole world was SQL. Hard to believe it's fading into the background.<br />Progress and Moore's Law make everything esoteric after a while. I wouldn't group SQL in with Assembly (for a number of reasons), but it appears ORM's have become common and efficient enough to make SQL knowledge obsolete, for web programmers, at least.Carl Trachtehttps://www.blogger.com/profile/12363048245012413049noreply@blogger.comtag:blogger.com,1999:blog-684183198890094283.post-64111346911792003432009-07-31T12:19:55.293-04:002009-07-31T12:19:55.293-04:00Mike's right, and I'd say most systems I&#...Mike's right, and I'd say most systems I've worked on in the past few years have been of that size.<br /><br />There's another way to architect a large system, however. If your system of record is under heavy load, and you are therefore already caching most of your child objects, it can be faster to farm your query out to a replicated repository (like Lucene), fetch a list of ids, and then fetch objects from the cache.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-684183198890094283.post-32783508254969938192009-07-31T11:30:32.391-04:002009-07-31T11:30:32.391-04:00> "But wait!" the SQL purist cries, &...> "But wait!" the SQL purist cries, "isn't that inefficient?" The answer is "rarely".<br /><br />I'll have to disagree with you there. There answer is, "if there are many parent rows, yes". Fetching a single result set is definitely faster than executing hundreds of individual SELECT statements. SQLAlchemy, as you know, abstracts the JOIN in the "first grab each parent item, then grab each child item" problem into a feature called "eager loading". So I don't think the problem is JOINs per se but just being able to use them appropriately in conjunction with an object model.mike bayerhttps://www.blogger.com/profile/01417862951114999907noreply@blogger.comtag:blogger.com,1999:blog-684183198890094283.post-67682848687727637762009-07-31T09:28:02.676-04:002009-07-31T09:28:02.676-04:00You might be interested in RQL which is similar to...You might be interested in RQL which is similar to SPARQL and CubicWeb's way to get data from the database.<br /><br />http://www.logilab.org/project/rql<br />http://www.cubicweb.org/Anonymoushttps://www.blogger.com/profile/06016708866434699070noreply@blogger.com