W
WardBell
Anybody know of Database Design Tools for Access?
wb
wb
T
TC
Pencil & paper. Seriously!
In the data modelling phase, I always draw the tables on a piece of paper -
just like the Relationships screen. For each table, I write the primary key,
and at least one other (non-key) element. This lets me develop & validate
the data model, *before* I start creating the tables.
HTH,
TC
In the data modelling phase, I always draw the tables on a piece of paper -
just like the Relationships screen. For each table, I write the primary key,
and at least one other (non-key) element. This lets me develop & validate
the data model, *before* I start creating the tables.
HTH,
TC
T
TC
Sleeping on it also helps to flatten-out unnecessary hierarchies!
TC
TC
S
Steve Schapel
I agree 100%. I would also add, keep an eraser handy when drafting
the plan. And sleep on it (no, I don't mean the eraser!), before
switching on the computer.
- Steve Schapel, Microsoft Access MVP
the plan. And sleep on it (no, I don't mean the eraser!), before
switching on the computer.
- Steve Schapel, Microsoft Access MVP
W
WardBell
Thank you for the comments. Pencil, eraser. What are they!
WB
WB
J
Joan Wild
TC said:
How about pieces of paper. I use index cards, one for each table - easier
to move around.
T
TC
Joan Wild said:
I guess you would be putting all of the table's columns, on each card?
I usually have just the primary key field(s), and just one other (non key)
field. So I would not have enough columns, to warrant a seperate card per
table
TC
S
Steve Walker
J
Joan Wild
TC said:
Eventually, but no, not to start.
I usually have just the primary key field(s), and just one other (non key)
field. So I would not have enough columns, to warrant a seperate card per
table
By the time you're finished you would, and you can move them around easier.
T
TC
easier.Joan Wild said:
The difference is probably this: I do not model /all/ of the columns on
paper. For example, once I have EmployeeID (PK) & forname (non key
attribute), I leave it at that. Then, when I'm happy with the overall model,
I go crazy with the extra fields when actually creating the tables. I find
this is a reasonably compromize bwteen modelling /everything/, and modelling
nothing
TC
A
Albert D. Kallal
I do use Visio for some initial design work. However, once I start adding
fields, I then use the built in tools in ms-access.
In fact, a lot people don't realize that you can right click and jump right
into table design mode from the er window (the relationships window). Hence,
for most appcltions, the tools included in ms-access are good enough. I do
miss the ability to "hide" the field names like the sql Enterprise tools,
but ms-access at least gives you some diagram tools for the tables. Not bad
all considering how affordable ms-access is.
Here is a screen shot of a design I layout with Visio, but then converted it
to ms-access. While Visio dos have to tools to actually create the tables, I
did it by hand.
http://www.attcanada.net/~kallal.msn/Articles/PickSql/Appendex1.html
The above was then converted into ms-access, and the resulting ms-access
tables:
http://www.attcanada.net/~kallal.msn/Articles/PickSql/Appendex2.html
fields, I then use the built in tools in ms-access.
In fact, a lot people don't realize that you can right click and jump right
into table design mode from the er window (the relationships window). Hence,
for most appcltions, the tools included in ms-access are good enough. I do
miss the ability to "hide" the field names like the sql Enterprise tools,
but ms-access at least gives you some diagram tools for the tables. Not bad
all considering how affordable ms-access is.
Here is a screen shot of a design I layout with Visio, but then converted it
to ms-access. While Visio dos have to tools to actually create the tables, I
did it by hand.
http://www.attcanada.net/~kallal.msn/Articles/PickSql/Appendex1.html
The above was then converted into ms-access, and the resulting ms-access
tables:
http://www.attcanada.net/~kallal.msn/Articles/PickSql/Appendex2.html
J
Joan Wild
TC said:The difference is probably this: I do not model /all/ of the columns on
paper. For example, once I have EmployeeID (PK) & forname (non key
attribute), I leave it at that. Then, when I'm happy with the overall model,
I go crazy with the extra fields when actually creating the tables. I find
this is a reasonably compromize bwteen modelling /everything/, and modelling
nothing
Well I guess I'll have to completely change my approach!