Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook



The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic

Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.

If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.

Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.

Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Database beginner needs design help

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Re: Database beginner needs design help

    Originally posted by jweasl View Post
    Thanks for the files Scott - I think maybe I got the first edition of the book, the appendix is a lot different.
    No Problem - My edition says 2nd Edition right on the front under the title....

    I'm starting to get confused
    My Dad once told me a story that I think applies here:

    One day two hunters were out searching for their quarry in Africa
    and they decided to split up to cover more ground. They also decided
    to meet back at the big rock at noon to see what each other had found.

    Well, noon came around and the older, more experienced of the hunters
    had his quarry down and motioned for the younger hunter to follow him.

    After walking for some time they came upon a clearing and the young
    hunter saw that the old man did indeed have his game down. It just
    happen to be a huge elephant!

    On seeing this the young hunter exclaimed, "Are you crazy??!! That
    animal is huge! How do you even think you could eat an elephant?"

    The older wiser hunter just thought for one moment. Then he calmly
    replied, "One bite at a time... just one bite at a time"

    My whole point here is - Don't try and think of this project as a huge
    elephant that you have to eat all in one sitting... Think of it as a bunch
    of little steaks that you cut up into little bites to eat. Break it down into
    a bunch of smaller chunks (projects) to accomplish.

    Remember that this is a work in progress. It probably will go
    through a bunch of changes before you are finished.

    So I fell like I should have a Machine Details table, Product Details, Purchase Order Details tables as well. Help please?
    There are many uses for the tables in a database. Some are informational,
    some are support tables - to ease data entry and
    provide consistancy to your users, some are linking tables to provide
    for the relationships.
    So to answer this requires the knowledge of what you are
    trying to accomplish.

    Use the book and try and follow the theories in it. He gives very
    good examples - The normalization process that Hernandez takes you
    through will tell you if you need a "details" support table.

    Good luck in the learning process!

    Holler back if you have more questions.



    • #17
      Re: Database beginner needs design help

      Ok new question. My company both re-sells products, and custom manufactures our own based on customer specs. When I place a purchase order, I purchase both raw materials (coil, sheet, etc) and pre-formed products (gutter, downspout, etc).

      Right now I have 2 tables setup - Materials and Products to track them separately. Do I also need to have 2 different Purchase Order templates? I'm setting up the PO table, so I have PONo as the unique ID, but then it has to refer to either a Material or a Product, and I don't think it can do both, right?

      Note: I am in the planning stage right now. After going through the book, I've decided to follow his advice and not touch a computer until the tables are all setup and everything.
      Last edited by jweasl; 06-17-2009, 05:57 PM.


      • #18
        Re: Database beginner needs design help

        I may be all wet but I don't see why you couldn't due what you want. A purchase order is a form in which you buy producs or materials from a supplier. Therefore you could many purchases from one supplier, or you you could have many purchase's from many suppliers. So my thought would be you would have a "JOB #" that would then have many purchase orders for that Job #. Does this make sense or did I confuse the isssue?
        I guess what I'm saying is have a table with Job information and the have another Table of purchase order information. Then create a set that creates the link that 1 job # could have many purchases.

        I hope this helps.


        • #19
          Re: Database beginner needs design help

          I'm setting up the PO table, so I have PONo as the unique ID, but then it has to refer to either a Material or a Product, and I don't think it can do both, right?
          My opinion: I think of a PO as kind of a link between the vendor and you. I don't know that it really matters what is on the PO be it raw materials or finished goods. I personally would go with one PO header for everything. You might want speak with your accounting / accountant to see how they want it. Typically they want all PO #'s, in order, no gaps, no duplicates, etc.
          One system would be easier to manage.

          You could base your lookup in to two different tables for products but you may want to consider that the structure you have might not be right. See below.

          Right now I have 2 tables setup - Materials and Products to track them separately. Do I also need to have 2 different Purchase Order templates?
          When I worked for a large (now defunct) computer MFG we had to do Cycle Counts and had a VA Process (Value Added) where we had to track each step of the manufacturing process for accounting purposes. The computers we built was made up of both finished materials and raw materials to make into a finished computer. Depending on where they were in the manufacturing process they were worth more ot one time than at another. I really go back and forth on whether the two should be split into two tables. On one hand if you have a single table it normalizes better because you are dealing with a single subject - Inventory. The state (adjective ) the inventory is in doesn't really matter with regard to the subject - Inventory.

          On the other hand as the raw product is converted in the manufacturing process, two tables is nice because you can show the consumption of raw materials as a "minus" and then have a matching record that adds it to the finished goods with the VA - labor, cost of goods & overhead.

          Hope that gives you some things to think about that you can use.



          • #20
            Re: Database beginner needs design help

            well part of the issue in my mind is the fact that Materials table and Products table have different characteristics. Keep in mind this is the first database I've ever designed, so large amounts of confusion on my part should not seem abnormal to you.
            Also, each of my products comes from a single manufacturer (I don't have multiple sources for the same thing), whereas my Materials do have multiple sources for the same thing.

            If that doesn't matter and my Purchase Orders should just link to both, great - I just wasn't sure if that was possible.

            Thanks for the help!


            • #21
              Re: Database beginner needs design help

              Jeremy -

              Not only is it possible it is pretty common.

              You would have a vendors / suppliers table and tie that in with your products and PO header. Take a look at the Alpha Sports sample db that ships with Alpha. That will maybe give you some ideas as to one way of tying things together. There is other ways to be sure but this is one possible way.

              Keep in mind that while you are trying to learn and follow some "best practices" methods you will have some trials and tribulations along the way. No one knows your needs better than you. The beauty of doing it yourself like you are, is that if something isn't working for you, you have the ability of making changes along the way.

              Just keep chipping away at it and before you know it you will have eaten an elephant!

              Later - in a way you can think of an order as a PO - one is between you and the customer - the other between you and a vendor. That is why I suggested looking at the Alpha Sports as well.


              • #22
                Re: Database beginner needs design help

                Hmm, always wanted to try elephant...

                So sounds like I just link to my Materials table and my Products table. Sorry for the confusion, that just sounds so weird to me (once again, db newb who's used to Excel).


                • #23
                  Re: Database beginner needs design help

                  I just got to thinking about another project I'm working right now that is very similar to what you are talking about. In this one however I'm dealing with products and services versus materials and finished goods.

                  Take a look at this thread on Complex Conditional Lookup and see if you don't see some similarity.

                  Mike Wilson came up with a really cool solution that I've incorporated in my application. The final is in post #73 here