oh, yeah I don't have that code, that was Ori talking about a particular client integration they had, where they went bananas with EAV. The point there was to show how Akiban does a much better job querying structures like that, but I had no involvement in that gig.
The EAV stuff I have, you can look in examples/vertical/ for a few old ones, then there's the http://www.sqlalchemy.org/trac/wiki/UsageRecipes/VersionedMap recipe which is more or less like the one I use in my current work, that's about it. As for use case, I'm all in favor of judicious use of almost anything. I don't respond well to the "never do XYZ!" thing, I feel like there should be a, "* unless you have more than 10 years of experience" clause (see http://norvig.com/21-days.html for background). I use, to a greater or lesser extent, all the baddies: global variables, mixins, multiple inheritance, EAVs, explicit locking, ORM queries in my controllers, all of it, if it's been called "bad" I've probably got it in production in a very judicious and pragmatic way, without problems. On May 16, 2013, at 3:48 PM, Lycovian <mfwil...@gmail.com> wrote: > I believe it was for some work you did for Akiban. If I remember correctly > (ha!) I believe you detailed with some slides an updated join strategy that > they are using (or that you hacked) into a custom version of SA used by them. > I noted the demo as I am planning on using EAV for a personal project and > was wondering if that updated EAV join strategy code would make it into the > released version of SA. From your slides I think you showed that the number > of joins on the EAV tables with the updated strategy was significantly > reduced. Sorry I can't remember more. > > As a side note EAV is not a panacea but I have used it to great effect in the > past judiciously. In the application in question we had millions of digital > assets in effectively a proprietary photo library used by Sony. All of the > data for the application except the binary asset was stored in the DB (Oracle > in this case). The requirement for the project was that the users could also > annotate their assets with security descriptors, groups, and any other typed > metadata they wished, including links to other assets to create "packages" of > assets. The metadata key/value count was going to be in the billions of > facts. As such we made the decision to make the entire of the metadata > schema EAV including internal metadata (security, stock keys such as create > date, name, path, etc). By putting all of the metadata in EAV we were able > to also employ such niceties as indexes for speed and table level constraints > (as well as triggers for certain keys and other business logic in PL/SQL). > The EAV method though did add some complexity to the application queries > which we abstracted away by using some Ruby ORM libs that could work natively > with EAV schemas hiding most of the complexity of the schema implementation > from the application engineers. Over all the project was a big success and I > believe is still in use with many billions of records, all without requiring > the use of a secondary key/value document store with differing query > semantics and iffy indexing and constraint enforcement. I wouldn't use EAVs > for everything, not by a long shot, but properly implemented and indexed they > work great in my practical experience. > > Mike > > On Monday, May 13, 2013 5:26:01 PM UTC-7, Michael Bayer wrote: > what video is that ? I don't use EAV's too often. If you can point me to > something I can identify what it was. > > On May 13, 2013, at 8:22 PM, Lycovian <mfwi...@gmail.com> wrote: > >> A few months ago I watched a video conference where Mike demo'd some >> optimizations for SQLAlchemy when using EAV schemas. Does anyone know if >> these optimizations will make it into the product that we have access to? >> I'm about to start a large EAV based project with SA and I was curious. >> >> Mike >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sqlalchemy+...@googlegroups.com. >> To post to this group, send email to sqlal...@googlegroups.com. >> Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
