Re: Concatenate and Null Values -- Features

I've only been doing this for a few years (and not full-time at that), and
am already embarassed by some of my early attempts. I am aware of Michael
Hernandez' Database Design for Mere Mortals, which I will be acquiring as
soon as I get organized enough to order it. The light has come on for me,
but I'm still squinting a lot. I'm also trying to decide how much
improvising I can do. For instance, I have a situation in which a number
increments 07-01, 07-02, etc., then starts over with 08-01 etc. next year.
It is a unique number, so I could make it the PK, but I would be storing
part of the date, which is already in another field. I could either add a
PK field, combine two fields into a PK (although I'm not sure what the other
field would be), or just go ahead and store 07-01, etc. In the first case I
am creating a new field in the parent table (autonumber, maybe); in the
second I am creating a new field in the child table, since a two-field PK
needs a two-field FK (as I understand it); in the third case I have one PK
and one FK, but arguably some redundancy in the date. So I ask myself if
storing part of the date like that is less redundant than adding a field
just so I can avoid storing part of the date. I've about decided to store
07-01, but my point is that I am thinking about this in a way that would not
have been possible a year ago.

"Tom Wickerath" <AOS168b AT comcast DOT net> wrote in message
news:D088C525-31BB-4DB7-AF4A-167A33ED48B5@xxxxxxxxxxxxxxxx
Hi Bruce,

For what it's worth, I floundered like a fish out of water for a few years
with Access. I had been attempting to work with Access since version 2 was
released. The light finally came on for me one evening back in '96 (or
perhaps '97) when I was at a meeting of the Pacific NW Access Developer's
Group. The speaker was Michael Hernandez, that author of the paper I cited
in
my previous post. Several of the examples of problems he showed were the
exact types of problems I had been encountering. I made an effort to start
studying database design after that, even though the subject can be a bit
dry. The effort really payed off.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"BruceM" wrote:

Hoopster, this is a lot of stuff being tossed your way, but it is really
good stuff. The people who have added to this thread since you posted
the
table structure are very skilled and knowledgeable (excepting this
posting;
I can claim only that I am making decent progress for a relative
beginner,
but I know good advice when I see it). I urge you not to be daunted by
all
of the new information. Once you start to get the hang of relational
databases you will have a powerful tool at your disposal.



.

Relevant Pages

  • Re: Concatenate and Null Values -- Features
    ... every table should have an autonumber primary key and it is not a good idea to use meaningful data for relationships. ... I am aware of Michael Hernandez' Database Design for Mere Mortals, which I will be acquiring as soon as I get organized enough to order it. ... I could either add a PK field, combine two fields into a PK, or just go ahead and store 07-01, etc. ... So I ask myself if storing part of the date like that is less redundant than adding a field just so I can avoid storing part of the date. ...
    (microsoft.public.access.reports)
  • Re: Using IIF with multiple values
    ... You may want to rethink your database design. ... Instead of storing the data as six ... fields in Table1, you should add a second table so that each of the 6 values ...
    (microsoft.public.access.queries)
  • Re: Auto Fill Date
    ... Why are you storing the date that is 6 months in the future? ... not good database design. ... form and use the DateAdd function to add 6 months to the DateAdded value. ... The help file can help you with the syntax. ...
    (microsoft.public.access.forms)