On Thursday 21 February 2008 00:47:16 jason kirtland wrote: > [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... ummm, what is "triple store"? (gogole abit..ahhha). waaaw. have i stepped on a landmine...
no i did not have an intent to design anything like that, but it just turned out... let me explain, WTF i'm doing last year and half. - app.field: HR/personnel - everything is bitemporal, including (some) pieces of code. - objects/classes have strict set-of-possible attributes (and their types, validation etc), but the classes can evolve in time, hence the set-of-attrs can change from version to version, (maybe) making the DB contain both old and new types. - some values can be multilingual, that is obj.country.value can be entered Deutchland or Germany or Alemagne depending on config; this is not just output-translation - so far, so good (uhm.. really?) - there are things/objects called "parameters", they control/parametrize the inner working of the calculations-engine (i.e. a "Salary" resource is computed out of many sub-salary-calculations, each having different parameters+sources/destinations) - any change in anything within current context-of-calculation and within current time-period splits the period into smaller time-cuts; a time-cut is considered final if anything relevant for the calculation stays constant in it - for each final time-cut, the calculation-engine is fired to calc the resources (re-)distribution - the parameters can be declared on different levels of calculational-mesh, but are value-filled / reside in different levels/places in object-data-structure (this concept is somewhat similar to the data-declaration/data-layout division for a c/c++ compiler, and maybe the item-layout/item-behaviour division in verilog et-al behavioral langs); there is a notion of transparency (inheritance) and shading (overload) of higher levels to the lower levels, value wise - its these parameters that i was talking about... i was going to put them in some "value-storage"... all this is needed as the (post-)socialistic employment law is very-very-very entangled... and gets worse so you say i'm screwed? )-:) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
