By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,836 Members | 2,139 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,836 IT Pros & Developers. It's quick & easy.

Table Design

P: n/a
Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistrationData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyData*
WarrantyID (PK)
RegID (FK) from tblRegistrationData
ClaimDate
"
"

tblBuildData details everything about the machine when it comes out of the
factory and the tblRegistrationData details when the machine was registered
after the customer buys it so the reason why the 1 -1 relationship. Warranty
claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other
machine data.

This design is now starting to kick me in the butt where I really notice it
now when my client wanted to be able to enter a claim against a machine if
it's unregistered if certain criteria was met. This wasn't foreseen a couple
of years ago was the system was designed. I got around this problem with
code by inserting a date in the RegDate field and then deleting the date so
the AutoNumber was created for the tblWarrantyData could then create a
record.

How would you have designed the tables?

I'll like to move all the fields from the tblRegistrationData to the
tblBuildData to simplify the design and improve reporting but that will be a
major with modifying all objects in the database and SQL in code that use
that table structure. About 350 objects.

Stewart
Nov 12 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistrationData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyData*
WarrantyID (PK)
RegID (FK) from tblRegistrationData
ClaimDate
"
"
How would you have designed the tables?

Probably with a single table.

I'll like to move all the fields from the tblRegistrationData to the
tblBuildData to simplify the design and improve reporting but that will be a major with modifying all objects in the database and SQL in code that use
that table structure. About 350 objects.

One option is to move add the extra columns to tblBuildData, delete
tblRegistrationData then create a query called tblRegistrationData using
tblBuildData. That way your existing code would not break until you have the
time to go through and replace all references to the query.


Nov 12 '05 #2

P: n/a
Hi Stewart,

If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
after you remove referential integrity. As always, make a backup of your
whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction
table makes sense in a many to many situation. As you have explained things
it's a logical part of tblBuild.

If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if
the back end is in Access. In this case, I'd be surprised if you're making
any meaningful use of RegID.

Are you aware that there are several that focus on specific parts of Access,
as well as this and another all-purpose Access newsgroup,
Microsoft.public.access.*

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistrationData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyData*
WarrantyID (PK)
RegID (FK) from tblRegistrationData
ClaimDate
"
"

tblBuildData details everything about the machine when it comes out of the
factory and the tblRegistrationData details when the machine was registered after the customer buys it so the reason why the 1 -1 relationship. Warranty claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other
machine data.

This design is now starting to kick me in the butt where I really notice it now when my client wanted to be able to enter a claim against a machine if
it's unregistered if certain criteria was met. This wasn't foreseen a couple of years ago was the system was designed. I got around this problem with
code by inserting a date in the RegDate field and then deleting the date so the AutoNumber was created for the tblWarrantyData could then create a
record.

How would you have designed the tables?

I'll like to move all the fields from the tblRegistrationData to the
tblBuildData to simplify the design and improve reporting but that will be a major with modifying all objects in the database and SQL in code that use
that table structure. About 350 objects.

Stewart

Nov 12 '05 #3

P: n/a
Hi John,

A single table is also what I was thinking about. Creating new fields in the
tblBuild, deleting the tblRegistration and creating a query sounds good.

Stewart
"John Winterbottom" <as******@hotmail.com> wrote in message
news:2g************@uni-berlin.de...
"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistrationData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyData*
WarrantyID (PK)
RegID (FK) from tblRegistrationData
ClaimDate
"
"
How would you have designed the tables?

Probably with a single table.

I'll like to move all the fields from the tblRegistrationData to the
tblBuildData to simplify the design and improve reporting but that will be a
major with modifying all objects in the database and SQL in code that
use that table structure. About 350 objects.

One option is to move add the extra columns to tblBuildData, delete
tblRegistrationData then create a query called tblRegistrationData using
tblBuildData. That way your existing code would not break until you have

the time to go through and replace all references to the query.

Nov 12 '05 #4

P: n/a
Hi Larry,

I intend to move all the fields from tblRegistration into tblBuild and then
recreate all the queries and SQL in code. The back end is
Access which makes the process easier.

What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is working
correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the new
copy of the front end.

Stewart
"Larry Daugherty" <La********************@verizon.net> wrote in message
news:1B*******************@nwrddc02.gnilink.net...
Hi Stewart,

If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
after you remove referential integrity. As always, make a backup of your
whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction table makes sense in a many to many situation. As you have explained things it's a logical part of tblBuild.

If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if the back end is in Access. In this case, I'd be surprised if you're making any meaningful use of RegID.

Are you aware that there are several that focus on specific parts of Access, as well as this and another all-purpose Access newsgroup,
Microsoft.public.access.*

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistrationData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyData*
WarrantyID (PK)
RegID (FK) from tblRegistrationData
ClaimDate
"
"

tblBuildData details everything about the machine when it comes out of the factory and the tblRegistrationData details when the machine was registered
after the customer buys it so the reason why the 1 -1 relationship.

Warranty
claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other
machine data.

This design is now starting to kick me in the butt where I really notice

it
now when my client wanted to be able to enter a claim against a machine if it's unregistered if certain criteria was met. This wasn't foreseen a

couple
of years ago was the system was designed. I got around this problem with
code by inserting a date in the RegDate field and then deleting the date

so
the AutoNumber was created for the tblWarrantyData could then create a
record.

How would you have designed the tables?

I'll like to move all the fields from the tblRegistrationData to the
tblBuildData to simplify the design and improve reporting but that will be a
major with modifying all objects in the database and SQL in code that

use that table structure. About 350 objects.

Stewart


Nov 12 '05 #5

P: n/a
Stewart,

Your planned approach is sound development practice except for the bit about
"on your time". Your company/client will be the beneficiary of the changes
you make. Why shouldn't company/client pay for the changes?

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi Larry,

I intend to move all the fields from tblRegistration into tblBuild and then recreate all the queries and SQL in code. The back end is
Access which makes the process easier.

What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is working correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the new copy of the front end.

Stewart
"Larry Daugherty" <La********************@verizon.net> wrote in message
news:1B*******************@nwrddc02.gnilink.net...
Hi Stewart,

If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
after you remove referential integrity. As always, make a backup of your whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction
table makes sense in a many to many situation. As you have explained

things
it's a logical part of tblBuild.

If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if
the back end is in Access. In this case, I'd be surprised if you're making
any meaningful use of RegID.

Are you aware that there are several that focus on specific parts of

Access,
as well as this and another all-purpose Access newsgroup,
Microsoft.public.access.*

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistrationData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyData*
WarrantyID (PK)
RegID (FK) from tblRegistrationData
ClaimDate
"
"

tblBuildData details everything about the machine when it comes out of

the factory and the tblRegistrationData details when the machine was

registered
after the customer buys it so the reason why the 1 -1 relationship.

Warranty
claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other machine data.

This design is now starting to kick me in the butt where I really notice it
now when my client wanted to be able to enter a claim against a
machine if it's unregistered if certain criteria was met. This wasn't foreseen a couple
of years ago was the system was designed. I got around this problem
with code by inserting a date in the RegDate field and then deleting the
date so
the AutoNumber was created for the tblWarrantyData could then create a
record.

How would you have designed the tables?

I'll like to move all the fields from the tblRegistrationData to the
tblBuildData to simplify the design and improve reporting but that

will be
a
major with modifying all objects in the database and SQL in code that

use that table structure. About 350 objects.

Stewart



Nov 12 '05 #6

P: n/a
I intended to mention about 2 emails back that there are some tools out
there that can be very helpful in making changes: Speed Ferret, a
commercial product and Find And Replace, a shareware product from Rick
Fisher. You can download Find And Replace from www.rickworld.com

--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi Larry,

I intend to move all the fields from tblRegistration into tblBuild and then recreate all the queries and SQL in code. The back end is
Access which makes the process easier.

What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is working correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the new copy of the front end.

Stewart
"Larry Daugherty" <La********************@verizon.net> wrote in message
news:1B*******************@nwrddc02.gnilink.net...
Hi Stewart,

If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID
after you remove referential integrity. As always, make a backup of your whole application before you start making changes. With the fields you
currently have it, tblRegistration looks like a junction table. A junction
table makes sense in a many to many situation. As you have explained

things
it's a logical part of tblBuild.

If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad if
the back end is in Access. In this case, I'd be surprised if you're making
any meaningful use of RegID.

Are you aware that there are several that focus on specific parts of

Access,
as well as this and another all-purpose Access newsgroup,
Microsoft.public.access.*

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi

Just asking for ideas on table design.

The design I have is as follows:

*tblBuildData*
BuildID (PK) AutoNumber
ManufactureDate
SerialNumber
"
"

*tblRegistrationData*
BuildID (PK) 1 - 1 from tblBuildData
RegID AutoNumber
RegDate
CustomerID
"
"

*tblWarrantyData*
WarrantyID (PK)
RegID (FK) from tblRegistrationData
ClaimDate
"
"

tblBuildData details everything about the machine when it comes out of

the factory and the tblRegistrationData details when the machine was

registered
after the customer buys it so the reason why the 1 -1 relationship.

Warranty
claims can only be made against machines that have been registered is
another reason why the registration details are separate from the other machine data.

This design is now starting to kick me in the butt where I really notice it
now when my client wanted to be able to enter a claim against a
machine if it's unregistered if certain criteria was met. This wasn't foreseen a couple
of years ago was the system was designed. I got around this problem
with code by inserting a date in the RegDate field and then deleting the
date so
the AutoNumber was created for the tblWarrantyData could then create a
record.

How would you have designed the tables?

I'll like to move all the fields from the tblRegistrationData to the
tblBuildData to simplify the design and improve reporting but that

will be
a
major with modifying all objects in the database and SQL in code that

use that table structure. About 350 objects.

Stewart



Nov 12 '05 #7

P: n/a
I'll still plan charge them. What I mean by in my own time is that since I
have a copy of the front and back ends, I can do it in my own time if my
client wants the changes instead of travelling to their premises. I have no
intention to do this much work and not get paid for it.

Stewart

"Larry Daugherty" <La********************@verizon.net> wrote in message
news:dZ*******************@nwrddc02.gnilink.net...
Stewart,

Your planned approach is sound development practice except for the bit about "on your time". Your company/client will be the beneficiary of the changes you make. Why shouldn't company/client pay for the changes?

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi Larry,

I intend to move all the fields from tblRegistration into tblBuild and

then
recreate all the queries and SQL in code. The back end is
Access which makes the process easier.

What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is

working
correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the

new
copy of the front end.

Stewart
"Larry Daugherty" <La********************@verizon.net> wrote in message
news:1B*******************@nwrddc02.gnilink.net...
Hi Stewart,

If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID after you remove referential integrity. As always, make a backup of your whole application before you start making changes. With the fields you currently have it, tblRegistration looks like a junction table. A

junction
table makes sense in a many to many situation. As you have explained

things
it's a logical part of tblBuild.

If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad
if
the back end is in Access. In this case, I'd be surprised if you're

making
any meaningful use of RegID.

Are you aware that there are several that focus on specific parts of

Access,
as well as this and another all-purpose Access newsgroup,
Microsoft.public.access.*

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
> Hi
>
> Just asking for ideas on table design.
>
> The design I have is as follows:
>
> *tblBuildData*
> BuildID (PK) AutoNumber
> ManufactureDate
> SerialNumber
> "
> "
>
> *tblRegistrationData*
> BuildID (PK) 1 - 1 from tblBuildData
> RegID AutoNumber
> RegDate
> CustomerID
> "
> "
>
> *tblWarrantyData*
> WarrantyID (PK)
> RegID (FK) from tblRegistrationData
> ClaimDate
> "
> "
>
> tblBuildData details everything about the machine when it comes out of the
> factory and the tblRegistrationData details when the machine was
registered
> after the customer buys it so the reason why the 1 -1 relationship.
Warranty
> claims can only be made against machines that have been registered
is > another reason why the registration details are separate from the

other > machine data.
>
> This design is now starting to kick me in the butt where I really notice it
> now when my client wanted to be able to enter a claim against a machine
if
> it's unregistered if certain criteria was met. This wasn't foreseen a couple
> of years ago was the system was designed. I got around this problem

with > code by inserting a date in the RegDate field and then deleting the date so
> the AutoNumber was created for the tblWarrantyData could then create a > record.
>
> How would you have designed the tables?
>
> I'll like to move all the fields from the tblRegistrationData to the
> tblBuildData to simplify the design and improve reporting but that

will
be
a
> major with modifying all objects in the database and SQL in code

that use
> that table structure. About 350 objects.
>
> Stewart
>
>



Nov 12 '05 #8

P: n/a
Good idea. It would speed up the changes.

Stewart

"Larry Daugherty" <La********************@verizon.net> wrote in message
news:S1********************@nwrddc02.gnilink.net.. .
I intended to mention about 2 emails back that there are some tools out
there that can be very helpful in making changes: Speed Ferret, a
commercial product and Find And Replace, a shareware product from Rick
Fisher. You can download Find And Replace from www.rickworld.com

--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
Hi Larry,

I intend to move all the fields from tblRegistration into tblBuild and

then
recreate all the queries and SQL in code. The back end is
Access which makes the process easier.

What I might do is to start making the changes in my own time with my copy
of the front end and a test copy of the back end. When everything is

working
correctly, back up their copy of the data, add the fields and change the
relationships and then run a couple of update queries then give them the

new
copy of the front end.

Stewart
"Larry Daugherty" <La********************@verizon.net> wrote in message
news:1B*******************@nwrddc02.gnilink.net...
Hi Stewart,

If tblRegistration is truly 1-1 with tblBuild then get rid of field RegID after you remove referential integrity. As always, make a backup of your whole application before you start making changes. With the fields you currently have it, tblRegistration looks like a junction table. A

junction
table makes sense in a many to many situation. As you have explained

things
it's a logical part of tblBuild.

If you make any changes to the schema there are likely to be changes
propogating throughout your application. However it shouldn't be too bad
if
the back end is in Access. In this case, I'd be surprised if you're

making
any meaningful use of RegID.

Are you aware that there are several that focus on specific parts of

Access,
as well as this and another all-purpose Access newsgroup,
Microsoft.public.access.*

HTH
--
-Larry-
--

"Stewart Allen" <sa****@NOT.wave.THIS.co.nz> wrote in message
news:c8**********@news.wave.co.nz...
> Hi
>
> Just asking for ideas on table design.
>
> The design I have is as follows:
>
> *tblBuildData*
> BuildID (PK) AutoNumber
> ManufactureDate
> SerialNumber
> "
> "
>
> *tblRegistrationData*
> BuildID (PK) 1 - 1 from tblBuildData
> RegID AutoNumber
> RegDate
> CustomerID
> "
> "
>
> *tblWarrantyData*
> WarrantyID (PK)
> RegID (FK) from tblRegistrationData
> ClaimDate
> "
> "
>
> tblBuildData details everything about the machine when it comes out of the
> factory and the tblRegistrationData details when the machine was
registered
> after the customer buys it so the reason why the 1 -1 relationship.
Warranty
> claims can only be made against machines that have been registered
is > another reason why the registration details are separate from the

other > machine data.
>
> This design is now starting to kick me in the butt where I really notice it
> now when my client wanted to be able to enter a claim against a machine
if
> it's unregistered if certain criteria was met. This wasn't foreseen a couple
> of years ago was the system was designed. I got around this problem

with > code by inserting a date in the RegDate field and then deleting the date so
> the AutoNumber was created for the tblWarrantyData could then create a > record.
>
> How would you have designed the tables?
>
> I'll like to move all the fields from the tblRegistrationData to the
> tblBuildData to simplify the design and improve reporting but that

will
be
a
> major with modifying all objects in the database and SQL in code

that use
> that table structure. About 350 objects.
>
> Stewart
>
>



Nov 12 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.