where to store report info

William Attwood wattwood at gmail.com
Tue Dec 9 23:16:57 MST 2008

Hmmm, if you want, you can do partitioning of that table, so it can grow
larger and respond faster.  The functionality is available in MySQl 5.1+.
I would recommend normalizing the data a bit more; a single table for all
clocking in and out, with a FK to a type of clock-in/out, and a FK to the
table (project, etc).

There are a few options.  How large is your table (rows, and physical size)?
 It may just be that you're using a server that isn't up to par with what
you need.  Hardware is cheap.


On Tue, Dec 9, 2008 at 5:12 PM, Kyle Waters <unum at unum5.org> wrote:

> William Attwood wrote:
>> Kyle--
>>   You could upgrade the hardware and/or enhance the storage of the data
>> through normalization, and RDBMS specific methods such as indexes.
> My main problem is that I have to subtract one line from an other, and then
> do different things with that data based off a different column.  I question
> weather I should actually have designed the database differently.  I
> implemented it based party off of how I'm reading the information in from a
> separate source.
> What this is is a time card database.  So there are two tables that matter
> for my current situation.
> Employees clock in and that is stored in one table with a row for clock in
> and clock out.
> Then they sign into a project that is stored in an other table and that
> stores info about having signed in and signed out.
> If they go to lunch, they are both clocked out and signed out.
> When they come back from lunch a new row is created in both tables.
> If they go on break they are signed out but not clocked out.
> If they go on break the time still is billed to the project that they were
> signed into when the went on break.
> When they come back from break a new row is created in the project sign in
> table.
> Maybe I should have a separate break table that keeps track of breaks
> rather than signing them out.  The current way is more in sync with the file
> that the data is being taken from(but increased time would probably be
> minimal), but the other would be more in sync with the out put.
> Kyle
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */

More information about the PLUG mailing list