[EMAIL PROTECTED] wrote: > slightly OT... >> http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/examples/ve >> rtical/dictlike-polymorphic.py > hmmm, figuratively speaking, what u describe above is a sort of > single-table-inheritance approach over a single-value "classes", one > per value-type, right? > > so u have objects, which have attributes of any name and a value of > one of the listed types. same-name attributes may have different > type-of-values allright. > > if a class/"value" has more than just the value (e.g. measurement, > units, scale, etc), and there are lots and lots of them, single-table > approach would be an overkill, i suppose. > Any specific recipe to follow here?
That example is more of a mapping recipe than a scratch design recipe: I've seen that "properties" table over and over in all sorts of legacy schemas. Sometimes it's just like that, sometimes it's shared storage for lots of entities and the setup is more like vertical.py. Sometimes it's worse and has foreign keys. If you *are* doing a scratch design of a triple store, then I'd personally look outside of the RDBMS. Perhaps the RDFAlchemy project, which I've been meaning to check out... --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
