On Sep 15, 2008, at 2:12 PM, Micah Gersten wrote:
You'll actually want to have the User Id in the clocking table, not
the
other way around. User Id is the foreign key because it has a many to
one relationship with the time logging.
Thank you,
Micah Gersten
onShore Networks
Internal Developer
You'll actually want to have the User Id in the clocking table, not the
other way around. User Id is the foreign key because it has a many to
one relationship with the time logging.
Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com
Philip Thompson wrote:
>
>
>
On Sep 15, 2008, at 10:59 AM, Micah Gersten wrote:
Use 2 tables. You never know what the app might grow into and you
should do it right the first time.
That's what I was thinking too... Just wanted to hear it from someone
else... NOW I get to learn about foreign keys and how to update thi
On Sep 15, 2008, at 10:03 AM, Jason Pruim wrote:
On Sep 15, 2008, at 10:59 AM, Micah Gersten wrote:
Use 2 tables. You never know what the app might grow into and you
should do it right the first time.
That's what I was thinking too... Just wanted to hear it from
someone else... NOW I get
On Sep 15, 2008, at 10:59 AM, Micah Gersten wrote:
Use 2 tables. You never know what the app might grow into and you
should do it right the first time.
That's what I was thinking too... Just wanted to hear it from someone
else... NOW I get to learn about foreign keys and how to update thin
Use 2 tables. You never know what the app might grow into and you
should do it right the first time.
Thank you,
Micah Gersten
onShore Networks
Internal Developer
http://www.onshore.com
Jason Pruim wrote:
> Hi everyone,
>
> I just wanted to make sure that I am not making something more
> compli
Hi everyone,
I just wanted to make sure that I am not making something more
complicated then it has to be.
I am working on a time clock application to use at my company, and so
far, I have a login table, and with a foreign key that links to the
time table. The thinking being, that when so
