Hi.

Your question is not a Firebird support issue, but I'd be happy to
take it off-line.

You are asking questions about the underlying schema, which means I
likely need more information. I have the following advice, though.
If you have an Activity Table, it should represent all of the common
elements of an activity (i.e. calories per hour burned, equipment
needed, attire, etc). If there is nothing UNIQUE about each activity,
I'd suggest adding an auto-incrementing key, which means adding a
Stored Procedure (in FB) to do the auto-incrementing.

Lastly, duration is not necessarily an element of the Activity, but an
element of the person DOING the activity (as is pulse rate). You will
likely need to create a table for those, too.

I'd be happy to take this off-line so as not to SPAM the rest of the
group. If anyone is interested, it might make a nice DB-101 course to
add to the sight documentation.

Regards.
Kurt.
federonline@...

> --- In firebird-support@yahoogroups.com, "kogerbnz" wrote:
>
> Hello
>
> First, if this question is off topic, please direct me to a correct
> newsgroup/forum. I think it's ok, but since the question is kind of
> general it may not be for this "Firebird" forum. Let me know..
>
> I'm starting using databases and choose Firebird because I'm
> developing in Delphi, heard a lot of good stuff about Firebird and
> have a "good feeling" about the quality, so far ;-)
>
>
> Here is the question:
>
> I'm making a training program, and you can add various "activities",
> running, biking etc. Some of the fields for these different activities
> will be the same, like heart rate, duration, time, but some will not
> such as distance when doing strength exercises.
>
> Since the activities are different, my first thought was to make a
> table for each activity, as this seems to be the nicest way to order
> things.
>
> I want to make a summary on exercise time in a week, and will be
> querying all activities and sum up the time. This tells me that it
> would be easiest to have all activities in one table
>
> 1) Should the common fields be in a common table or be in each
> activity table?
> 2) Should I instead have one big table for all activities?
> 3) Something different.
>
> Please remember that I'm a quite new to databases and don't know SQL
> that well yet. The lack of SQL might lead me to focus on a wrong
> solution, so the answer may be very simple to you :-)
>