Is this right?

[ATLBryan]

Hi,

I've created a database solution on my own for the first time. It seems to work alright, but just wanted to check something. My table is a contact list of various people associated to specific jobs. There are a ton of different positions and some people do only 1, some do many. I have them broken into groups such as product managers, product development, lead, etc... I'm able to create a bunch of cool reports either job specificly or person specific. Everything's seems set up nicely, but I have a question.

The backbone of my solution is a large table of numbers, all the serial numbers associated with each entity. Is this normal? Is it a good idea? Typically when updating all I have to do is update the record and boom it's done, and when changing people in and out of jobs, i only have to change the number in the right spot.

I'm mainly just curious if this all sounds like a normal solution with about 15 different tables (some 1-1 stuff, 2-1 stuff) and one giant center table of numbers.

Anyone?

[Ender]

We'd need to know about the specific tables, fields, relationships, and what the business needs are in order to say if what you have is good.

Although there are exceptions, in general, one-to-one relationships can be eliminated and the tables combined. One-to-many relationships are much more common. I have no conception what your giant table of numbers is.

[comment]

I am guessing it's the join table between people and jobs?

[ATLBryan]

i don't know what a join table it, but it sounds right. but i have 1 table with a list of all the job names... and each job has 15 or so ppl associated to it. (for 120 jobs)

The solution is basically a contact database. I have people grouped by job function.

Edited April 21, 2007 by Guest

[Ender]

If you only have one table to handle all this, then no, it would not be a good structure.

If you have multiple tables, then we still don't know what they are, what fields they contain, and how they're related.