Celal, whatever works is my philosophy :) We all do things differently, and all ideas have some merit. Most important is to be consistent and stick to it (until there is a better idea). The more you can inject logic, the less there is to remember
another design tip: don't jump into table design without first gathering examples of current data entry forms, reports, and every type of file that might have related data in it. Print a page of everything important and clear off a big table. Put all the papers there and organize them. Then you are ready to start planning what tables are there ... and from that comes everything else
In Access, build the relationships as tables are built and use the relationships diagram as a tool to see what you have. Show all tables even if they aren't related (yet)
Put at least one test record in every table to test your design and relationships. When you are entering data, you are seeing what you have from a different perspective.
Learn Access Playlist on YouTube
~ have an awesome day ~
I'm no pro but to put in my 5 cents, I always start with a pencil, eraser and notepad after I have visualize something in my mind. I did make the mistake of jumping right in by making dummy tables from scratch which led to dozens of versions of the database and took much longer time and frustration and confusion. after sratching out with pencil, eraser and notepad, I make a plan of tables and relations, forms and querries in an excel workbook before everything
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com]
Sent: Thursday, February 11, 2016 9:40 PM
Subject: Re: [MS_AccessPros] Designing a new database
When I first started designing databases, I got 11x17 paper and sketched the tables, fields, and relationships with pencil (and erased a lot, lol!). Now that I have built hundreds, maybe thousands, of different databases, I start by designing the tables and relationships in Access. As I go, the relationships diagram is laid out and documented with screen shots and annotated in PowerPoint. Very important to also fill field descriptions, in my opinion.
video Tip: Enforce Referential Integrity on Access Relationships (cc) closed-caption
It is helpful to create a separate directory for each project. That is how I keep my notes about a project organized. Glenn likes OneNote, as do many others. I prefer keeping notes in files and organizing the files.
Everything is an essential free tool in my kit
Everything is amazingly fast for finding files once it builds the initial database. In fact, I can usually find a file faster with Everything than I can navigating to where it is when I know the exact location. So, for instance, if you are looking for a Word file with daily and sales in the name, you can type:
doc daily sales
as you type, separate things with spaces. You can also use wildcards.
To Copy Path to Clipboard, or the Copy Full Name to Clipboard, right-click the file in Everything, and choose from the shortcut menu to copy and then paste wherever you like. Double-click on a file to open it, or right-click and Open With. You can also drag files, or ctrl-drag (to make a copy) from Everything to a folder.
Everything is in the system tray when it is running (it loads automatically, which is one of the few things I let do that).
I make a hotkey of Ctrl-Alt-Shift-\ to launch Everything anytime -- and I use it several times a day.
Tools, Options, Keyboard
When Everything installs, check box for context-senstive menus so you can right-click on a folder in Windows Explorer or My Computer and limit Everything to searching below a folder.
Hope Everything can help you too.
~ have an awesome day ~
On 2/11/2016 12:16 PM, 'Glenn Lloyd' email@example.com [MS_Access_Professionals] wrote:
I use OneNote a lot to organize my notes and diagrams. One trick I use when thinking and writing about my specifications is to state everything as if the project were complete. Some years ago I developed a couple of templates for guiding my discussions with clients in the early planning stages. I'd be happy to share them with you if you think they might be helpful.
You and I seem to be in agreement. Now, how to accomplish this feat of daring?
There are a lot of Word and Visio templates out there to document what you did and why but they are after the fact. Do you just use a greaseboard to write everything out or is there something more structured?
In my not so humble opinion, proper planning and designing is far more important than the actual construction (tables, etc.) of the database itself. Jumping in and starting to create the tables before having a comprehensive design based on a detailed needs analysis, is an open invitation to a time consuming exercise in frustration. A colleague of mine at UA has a signature line that goes something like this, shortcuts lead to long delays.
The 80/20 rule is as relevant here as it is elsewhere. Development should be roughly 80% planning, and 20% implementation. The planning component include needs analysis and data analysis. With thorough planning, data definition virtually becomes child's play.
The same goes to developing the user interface (frontend).
I know Crystal has a killer tool for documenting a database that already exists but this is about a green field database. ....starting from scratch.
When one of you pros start designing a new database for a client, do you start by writing up the design (tables, fields, field properties, FKS and relationships to other tables, field comments, etc) or do you just start setting up a dummy set of tables?
Same question for queries, forms, and reports.
Posted by: crystal 8 <firstname.lastname@example.org>
|Reply via web post||•||Reply to sender||•||Reply to group||•||Start a New Topic||•||Messages in this topic (16)|