Between a wiki and a database?
-
Hi all,
I've had this idea in my mind for a while now, and finally feel like starting on it. I'd just like this scrutinized by fellow coders - whether the idea makes sense, whether there is already a similar software, whether there is something you'd like changed in the plan and whether it's worth attempting in the first place.
A long time back, I was asked to make a software that could be used to store a lot of collected information. It was going to be used for a small nature survey project - information about the species being studied and specific observations made during the survey. Without thinking much, I'd made a simple software that just stored data in fields, displayed it using a web interface and allowed you to edit it. When I showed it to everyone, I realized one flaw - I'd hardcoded the various fields (genus, species, common name, height, weight, etc) for each type of species (plants, mammals, insects, etc).
I thought then that the way to store information about the structure of table and have the program work with that information to create tables and edit and display information. This seemed too complicated, so I just used a wiki.
The wiki, however, never worked out because using things like templates was too complicated and people didn't really want to understand how to work with a wiki. It was MediaWiki, so the reaction was "that's like our own Wikipedia!". I later found out that editing the raw source of a wiki page is often too much to ask of lay (?) people and explaining how to make and edit templates for different categories was too much to ask. Finally, a wiki didn't have the kind of advanced search features that may be required here.
In retrospect, I can see that an extremely simplified interface to a database was too rigid and a wiki's lack of structure and (if you look at it from this point of view) excessive flexibility made it too complicated to create structure.
(Continued in comment - exceeded character limit)... -
Now I want to write something in-between. I spent sometime planning, very roughly, the design of another software that I'd like to find/create. I'd call this some sort of a document database. Each document will have a category, with recommended fields (height make sense of trees, but not for medicines, software and insects, so it will be a recommended field for trees), a name, a long description and any number of user created fields (out of thousands of popular people, the only for the few who contribute to FLOSS can provide a sf or launchpad homepage, so such a field will be a user-created field made at the time of creating or editing the document).
It can have sophisticated search features with a simple interface - I can see complex AND/OR criteria without daunting the layman. The long description can be formatted with Markdown, etc. I've just started learning CouchDB and it seems like the perfect way to implement this. If I'm going to write it, I'll do it in Python so that two compatible interfaces - a desktop and a web - can run side by side.
Fire away! -
What is exact reason for a desktop application? I really see no reason for it. A web interface is easy to build and use.
Am I right that you want to create backup files in case someone tried to ruin everything, right? Well, I would keep my DB clear with just 1 (the right) copy of the document + backup previous versions in separate files (file name would be a timestamp, probably). I see no reason for any other DB than MySQL. It's pretty universal :)
For editing, I would use any WYSIWYG script. It usually simplifies editing even for beginner users. I think TinyMCE would be pretty good. It has a lot of functions and it's open source either :)
P.S. I don't understand the part with 'tables being too complicated'. On web, everything is inside a table or box. -
I personally think that the easiest way to solve the original problem would be to allow "user columns." My approach would be to have a table with all of the 'standard' columns (genus, species, etc) and then if the user needs extra fields for other data, just tack on another column (possibly named like 'user1', 'user2', 'user3', etc) and store what those columns represent in another table.
However, what you're describing here is exactly what OOP is all about! To use your example, a tree, you could have a tree class w/ properties for all of the 'standard' properties that you could want. Then you could just serialize the data for each class instance and store that in a db row. Although I'm not exactly sure on how to be able to extend the class, it probably wouldn't be too hard (depending on the language). -
(Character limit problems again, I've broken this reply into three comments)
@Vento: I was thinking a desktop application so that it would be easier to deal with when someone wants to store information locally. Getting a LAMP type server would be too complicated then.
I don't really know whether a relational DB like MySQL would make sense. How would I be able to get flexibility with fields? CouchDB, being a document-oriented database would be much simpler.
About tables. Well it's got to do with the markup. If I wanted, like on many wikipedia pages, an info table floating on the right hand side of the webpage, I'd have to make a template for that. That's fine. Except that teaching people how to edit the template and use the template wasn't very easy.
-
@ddreier:
All this is super easy with CouchDB. There is no fixed structure and you use map/reduce to search through the database. Far less complicated than 'user1', 'user2', etc because there's no way you can have an infinite number of such fields and having a program deal with constantly changing table structure seems excessively problematic.I personally think that the easiest way to solve the original problem would be to allow "user columns." My approach would be to have a table with all of the 'standard' columns (genus, species, etc) and then if the user needs extra fields for other data, just tack on another column (possibly named like 'user1', 'user2', 'user3', etc) and store what those columns represent in another table.
Yes and no. It is like OOP, but if I actually made all these things happen in the code rather than in the db, I would (yet again) be hardcoding structure.However, what you're describing here is exactly what OOP is all about! To use your example, a tree, you could have a tree class w/ properties for all of the 'standard' properties that you could want. Then you could just serialize the data for each class instance and store that in a db row. Although I'm not exactly sure on how to be able to extend the class, it probably wouldn't be too hard (depending on the language).
What I'm thinking of is a generic program that can be used to store any information in any format, without forcing a structure (like in a DB) but with the advantages of a db that a wiki doesn't have - search capabilities, a sort of recommended structure that a UI can be built around.
-
I'll explain both here, so that I'll know whether my ideas make sense or not.
You can only search through a wiki with text. You cannot, say, filter stars by their distance from the sun, shrubs from a list of trees, etc. Because such information will be stored in explicit fields, it would be possible to have complicated search queries like these.
If such a program was simply a UI for a traditional relational database, it would be possible to create a great and powerful UI because the structure is fixed. In a wiki, however, there is no structure at all. So even to make something like an info box on the right hand side would require the use of a template. Like I've already said, this isn't easy for not-so-tech-savvy people to do. This program will be an in-between in that there will be a direct use of "fields" which will allow the two capabilities I've mentioned above.
One of the reasons I'd like to have this idea scrutinized is that there are so many sophisticated database UIs and so many wiki engines. There's a good chance that what I'm imagining is already implemented or can easily be done by modifying a good wiki engine that people have already spent a great deal of time working on.
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!