If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#41
|
|||
|
|||
I think I'm almost there...except for...
"Immanuel Sibero" wrote:
To use Craig's fish analogy... You first try to teach him how to fish, if that fails then give him a fish. The problem is, he doesnt even know it's a fish. Very succinct. I think I'm going to make that into a poster for my office. |
#42
|
|||
|
|||
I think I'm almost there...except for...
mnature, Very succinct. I think I'm going to make that into a poster for my office. I have a fish tank in my office :-) I think you are the only one that got through to the OP. We all should thank you for your persistence. I have a feeling the OP will be back. Immanuel Sibero "mnature" wrote in message ... "Immanuel Sibero" wrote: To use Craig's fish analogy... You first try to teach him how to fish, if that fails then give him a fish. The problem is, he doesnt even know it's a fish. Very succinct. I think I'm going to make that into a poster for my office. |
#43
|
|||
|
|||
I think I'm almost there...except for...
My database is a lot simpler than you think.
Employee Currentwork (what does this mean? My note: Are they working for the company or not) Calender EmployeeID (FK) YearID (Why are you putting this in? Why not just have a simple date, and extrapolate whatever you want from that date? My Note: I know it now!!!!) MonthID (Again, why??? My note: same again) WeekID (PK) (You cannot make this a true week-of-the-year number, and also have it as the primary key. Your database fails with this particular field alone. As soon as you start putting in data, that should become obvious.) My note: WeekID is in the xx/xx/xxxx format. Department (no primary key? My note: Don't need one) timehalfhrs (Why are you defining the type of hours in a field name? My note: Type of hours: simple Numerical format. How many overtime hours worked at 1*5 times the hourly fee dbletimehrs (You are going to put in two types of hours within one record?) My note: Type of hours: simple Numerical format. How many overtime hours worked at twice the hourly fee. Yes I do have a key: weekID. |
#44
|
|||
|
|||
I think I'm almost there...except for...
I've made it into a poster:
You find a starving man First, try to teach him how to fish If that fails, then give him a fish If he is still starving, the real problem could be Not that he is starving But, that he doesn't even know What a fish is |
#45
|
|||
|
|||
I think I'm almost there...except for...
WeekID (PK) (You cannot make this a true week-of-the-year number, and
also have it as the primary key. Your database fails with this particular field alone. As soon as you start putting in data, that should become obvious.) My note: WeekID is in the xx/xx/xxxx format. scubadiver, no matter what format WeekID is in, if it is declared a primary key, then it is required to be unique. If you attempt to use the same WeekID for two employees, the database will bring up a warning, and not allow you to do that. So, how are you going to handle having more than one employee per WeekID? |
#46
|
|||
|
|||
I think I'm almost there...except for...
Jamie Collins wrote: Craig Alexander Morrison wrote: The best and most practical advice is learn how to normalise your data I am of the opinion that 'Learn how to normalise your data' falls some way short of the most practical advice. Actually, I consider it a non-answer, right up there with 'Learn how to do DBMS design' and 'Learn how to program'. In the interest of fairness, I trawled fir the ten most recent replies mentioning normalization (although I admit to saving the best one until last). Although none were very specific (would you believe it wasn't until the eleventh that 3NF was name-checked g?), there are not as many 'cringers' as I was expecting: "a more normalized structure" "isn't normalized" "in need of normalization" "Keep it well-normalized" "properly normalized" "a different normalized format" "NOT the best normalized method" "good normalization" "a normalized union query" "is not strictly normalized" "search for normalisation on the web and you'll find the rules which should be applied to a database in order to make it relational" |
#47
|
|||
|
|||
I think I'm almost there...except for...
Jamie, you are bringing up some good points. Speaking of normalization as if
it were a self-evident expression is certainly not helping people. However, there are a number of posts to this forum, where it is obvious that these people have no experience in programming Access other than the ability to click on an icon to open the program. Isn't it fair to say that if they are sent off to search for information about normalization, that they will probably stumble across other information about programming databases, and thus become better able to do whatever project they want to do? In the case of scubadiver, it would be better for everyone if he would go out and buy a few beginner books about Access, and then actually read them. I would like to ask you directly, then: What is the best way to talk to someone who seems to be rather clueless about databases? Some people seem to respond quite well to being told to study the subject, and come back a few days later with some excellent questions. Some people respond well to actual samples of what we think they need (learn by example). Some can be told to think of each table as a separate subject, and intuitively grasp the concept of normalization through that. I look at it as a graded approach to the problem, depending on how the problem is presented. Someone posts some tables, you mention they are in need of normalization. They come back with different tables, and you realize they have no idea what normalization is, so you tell them to go learn normalization. They come back with even different tables, that are an even worse design, so you post what you think their tables should look like (basing that upon whatever clues they have given about what they are trying to do). You also try to explain, in simple terms, what is meant by normalization. By this point, they usually are starting to understand. But not always. So, is there a better way to proceed? |
#48
|
|||
|
|||
I think I'm almost there...except for...
mnature wrote: I would like to ask you directly, then: What is the best way to talk to someone who seems to be rather clueless about databases? is there a better way to proceed? I can only repeat repeat what I have said up thread: Explain in which normal form (if any) you think the OPs design is currently, which of the normal forms he should be aiming for and - to give it the practical element lacking thus far - what you think he needs to do to get his design to your recommended normal form. [Use] phrases to make you advice more practical: "By doing x you have violated 1NF." "You could y and your design will be in 3NF." Jamie. PS ...or do as I do and don't give advice pertaining to normalization g. -- |
Thread Tools | |
Display Modes | |
|
|