Ok, so this is kinda out of the blue... but I've been looking at Google Base and thinking that it's got some really good ideas in it. Especially the way you can create your own "type" of item with its own custom attributes, like date range, location, number, text, etc. Kind of like defining a database with a GUI, but not exactly. It seems really interesting to me, from a sort of content management perspective. The hardest part for me is getting my head around how you'd structure the database tables to do this. It's a lot like making an application that lets users build their own surveys, if that makes sense. Is anyone working on something remotely like this?
on 2006-04-11 11:19
on 2006-04-11 11:22
in essence... table Models table Fields class Model < AR, etc has_many :fields end On Tuesday, April 11, 2006, at 12:17 AM, Raymond B. wrote: >sense. Is anyone working on something remotely like this? >_______________________________________________ >Rails mailing list >firstname.lastname@example.org >http://lists.rubyonrails.org/mailman/listinfo/rails Mikkel B. www.strongside.dk - Football Portal(DK) ting.minline.dk - Buy Old Stuff!(DK)
on 2006-04-11 11:30
Mikkel B. wrote: > in essence... > > table Models > > table Fields > > class Model < AR, etc > has_many :fields > > end > > > > On Tuesday, April 11, 2006, at 12:17 AM, Raymond B. wrote: >>sense. Is anyone working on something remotely like this? >>_______________________________________________ >>Rails mailing list >>email@example.com >>http://lists.rubyonrails.org/mailman/listinfo/rails > > > Mikkel B. > > www.strongside.dk - Football Portal(DK) > ting.minline.dk - Buy Old Stuff!(DK) http://www.dabbledb.com/ There is one written in rails, but it isn't so good and I can't remember the url.
on 2006-04-11 14:52
On 11/04/2006, at 7:17 PM, Raymond B. wrote: > It seems really interesting to me, from a sort of content management > perspective. The hardest part for me is getting my head around how > you'd structure the database tables to do this. It's a lot like making > an application that lets users build their own surveys, if that makes > sense. Is anyone working on something remotely like this? I'm working on something that's very vaguely similar. It's not of the scaled that Google Base is, but the fields can contain various types of data. The easiest way is to have two tables, on with field descriptions and one with data. However, when a customer calls up asking you to do a complex data query it gets tricky. I've come up with a postgresql specific system that dynamically creates and modifies the data storage tables for each user. It's probably far more complicated than it needs to be and a bit fragile in some places, but it works. As a bonus it gives you a real ActiveRecord object, though you can't use the association methods.
on 2006-04-13 18:20
On 4/11/06, Phillip H. <firstname.lastname@example.org> wrote: > The easiest way is to have two tables, on with field descriptions and > one with data. The problem I'm having trouble getting my head around - or finding code samples for - is letting folks create their own data set. Let's call it a Survey. I want users to be able to create any number of Surveys, each of which contain a number of "rows" just like in a database. How would you store the fact that one survey "question" takes a text area, and one takes a date, and one takes an integer, etc.? Can anybody suggest a not-so-fragile, best-practice way of tackling something like this in a database?
on 2006-04-13 18:33
<snip> > There is one written in rails, but it isn't so good and I can't remember > the url. > Hi Joey, Do you mean http://www.myowndb.com ? Why the not so good? Let me know, I'm interested! ( You're the first negative comment I see about the app.) It's in full development and has had some additions since the announcement (see http://www.myowndb.com/blog/ ) Cheers Raph
on 2006-04-13 21:36
class Set < ActiveRecord:Base has_many :rows end class Row < ActiveRecord:Base belongs_to :set # has an id, a type, a Text field called "value" end class IntegerRow < Row def value super.value.to_i end def value=(input) super.value = input.to_s end end class TextRow < Row #no accessors needed end So, basically what we are using is the subclass idea built into Rails. There are only two tables in the db in this example, but "types" associated with each row. In my super-simple example, a TypeRow is just an accessor wrapper around a Text field in the db that does converstion. You won't have the smallest DB in the world and you couldn't do built-in db calculations on numbers. But, otherwise you could go crazy defining rows... "PersonRow" could return a first and last name, etc. -hampton. -hampton.