5 thoughts on “DabbleDB: coolest web site I’ve seen this week

  1. That’s really sweet. Excel does some of it with Pivot Tables and Pivot Graphs, but nearly as smoothly.

    The piece that intrigued me the most is the ability to create new database tables, and then move columns between the tables. To get really geeky for a second, I wonder what happens if I move a column to a table where the column’s relationship to that table is one:many (or even many:many). In the video, it was 1:1, and it figured out which companies belonged with which presenters or whatever. But if it were 1:many, would it create duplicate rows to include the new attributes? Would it create a separate xref table? Would it pop up an error message?

    Curiouser & curiouser…

  2. @Brian: internally any relationship is effectively many:many, although you can choose whether to present it as one:one, one:many, or many:many in the UI. All of the xref tables are hidden from the users. And incidentally, presenters:companies is one:many – you can (and that data set does) have more than one presenter in each company.

    We’re excited about these “data refactorings”, and curious what others we can come up with that can still feel simple and natural to users. If you have any ideas along these lines we’re happy to hear them.

  3. OK, first of all, let me just say how cool it is that you guys are checking around the blogosphere for comments about DabbleDB, and responding indivdiually to questions. I cross-posted about it on my blog as well (doing my part to extend your exposure). Well done. Very well done.

    Now, as to your response: glad to hear you guys thought about it, but I’m curious about what happens in that case: If presenters:companies is one:many, what does it do in the new table if a presenter represents two companies? Is it two rows in the table? Does that mean the software automatically extends the primary key of the table to include company? Would it do that even if the relationship was 1:1 (as defined by the data)? Or is it a 1-column key, with duplicates allowed? I could see that causing problems later with joins that are represented by simple hyperlinks. It sounds like a sticky problem to me…

    Thanks again for your attention. As I said, I’m very impressed.

  4. Brian,

    The first thing to point out is that we don’t use a traditional RDBMS as the backend – we’ve got a custom object database (though very relationally influenced in design) that manages this stuff.

    However, in RDBMS terms, the simplest way to describe what the internals look like is that each field the user defines maps to a separate *table* in the backend, which has two columns (source, target), neither of which has to be unique. That make any sense?

  5. Yup – makes sense. Pretty slick architecture too. But what about the user’s experience. The video showed the user clicking on a presenter and popping open a new table (or at least the graphical representation of one). What do you show the user when the relationship dictates 1:many?