On 1/3/07, Moxley Stratton <[EMAIL PROTECTED]> wrote:

Without going into the proprietary details of the project, I'll use a
metaphore. There's a particular part of the application that is a like a
user-defined database, where the user can define the schema. For this
discussion, I'll call this user role a Maintainer. There may be
thousands of Maintainers, each with their own database.

Because that a) the databases are user-defined, and b) there will be
thousands of them, I'll make the assumption that Maintainers cannot have
their own physical database (or physical set of tables). Instead, a more
exotic scheme would be needed. What will that scheme look like? I'm not
sure. The first idea that popped in my head involved storing XML in an
RDBMS that knows how to query XML (e.g., MySQL can).


I'm having two thoughts.  The first thought is along the lines of what
Moxley is thinking -- do your own thing.  In that case it starts to sound a
lot like what Avi Bryant talks about with respect to dabbledb. Apparently
for dabbledb they built all kinds of home made indexing and query stuff.
Unfortunately I think that stuff is proprietary and didn't get into
seaside<http://www.seaside.st/>
.

The other thought I'm having is a bit more subversive.  What about going
ahead and using mysql and going ahead and creating databases and DDL on the
fly.  I mean, you couldn't ask for a more dynamic language than Ruby if you
want to slap models on top of those custom databases on the fly.  I'm
envisioning something that kind of puts a point and shoot schema
manipulation thingie on a web page and creates Rails migrations on the fly
and applies them to user-specific databases potentially running in one big
mysql instance -- or maybe a farm of instances.

I guess it depends a lot on what you're good at and where you want to focus.
_______________________________________________
PDXRuby mailing list
[email protected]
IRC: #pdx.rb on irc.freenode.net
http://lists.pdxruby.org/mailman/listinfo/pdxruby

Reply via email to