API database

I'm currently working on building a database where we can store all the API calls.
Quote from an e-mail to the discuss@OOo list (discuss thread ) describing what I'm doing:
==========================================
OK, I ended up staying up till 3 in the morning thinking about the
problem. This e-mail kind of queued me into where I need to go and I
think I finally understood relational databases, and how this relates
to my problem.

OLAP is for analysis of data, not inputing it, though I'd really love
to be able to do something like "inverse-OLAP" putting in the data, in
a way that makes sense, or in the same way we view it. Maybe if I'm
ever lacking in a project to complete I'll work on doing something
like that. Until then, i'll make do.

So I have developed a design for a relational database that meets my
needs. I found that with a relational database (after I figured out
what I was doing) I could add some of the extra info into the database
that would have seemed slightly out of place in my cube design, though
it is very easy to see how a cube still applies to alot of the data.
In the end, my design is a 12-14 table database (there are still a few
questions on how I want to deal with a category of information). It's
still got 4 dimensions, but I added several tables to further
categorize and deliminate some info on all my info. Once I've finished
putting it in digital form, I'll post a link to my desing, and a link
to the final interface as I will want help populating it.

My main table consists of a lists of IDs from 5 other tables
essentially creating the "Array" that was mentioned.

The purpose of this database? to create a central storage place easily
accessible to more than just me for all of the toolkit API calls for a
specific feature(widget) on a platform. So my 4 'dimensions', and
subsequently the 4 main tables linked into my main reference
'array'-like table are:
Platforms
Toolkit
Features
API

Also, I designed the beginning layout for forms for data-input (forms)
and data-output (reports). I definately want to be able to have people
help me fill in my database so I'm looking at creating a form in PHP
or something like that with a MySQL backend. Either that, or I simply
host the database and offer a Base file that interfaces with it so
that people can view/modify the data. Or I do both. I'm not sure how
to deal with user accounts though. I'm afraid to allow anonymous
access because I can't afford the time to de-spam this. But I want to
give anybody who wants to help, access. Suggestions?

For Silver Onion I will select a feature, get a list of all the API
calls for that feature, dividing into specific platforms where
necessary, and create a new UNO API layer that will translate an API
that I will define into the APIs of whatever toolkit happens to be the
preferred toolkit on that platform, with a user option to override and
manually select a toolkit. That's the purpose of this database. I have
a blog devoted to this project at silveronion.blogspot.com Note
however that I write the blog for me and I periodically cross post
what I post there into a mailing list if I need input on a decision or
on how to do something. (Also note, that I'd love to get other people
to help me. I'm working on creating some well defined parameters that
I can then present with a call for help in programming it, because
well, I'm not the best programmer.)

Thanks for helping me to think of this in every so slightly a
different light that makes it possible to complete!

Thanks,
Jacob
- posted by techgurufloyd @ 3/16/2005 04:50:00 PM