Announcement

Collapse

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

Set Design?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Set Design?

    Hi All,
    I need to create a vehicle application that stores year, make, model as well as a parts table, my ? is should I create two or three tables to hold the vehicle info such as one table for the years, and one table for the makes and yet another table for the models?

    Or should I just make two table, one for the makes, and one that would hold
    the year and model for that make?

    My Main application would need to lookup the year, make, and model. I think this is the best set design but I would like others opinion on this set design.

    I understand linking and creating sets I just dont know if I should create two
    or three tables for the year, make, and model part of my application, and yes
    I now I will have to create yet another table or tables for the parts.

    I have decided this application is small enough to get me started with Alpha Five and I desperately need a vehicle database so this project is perfect for relearning Alpha Five as I have only dabbed with it over the years.

    Thank you
    Ray
    Kind Regards,
    Ray Roosa
    Raylin Micro, LLC.

  • #2
    Ray,

    You are a bit vague with what type of database you need. I know you said "vehicle application that stores year, make, model as well as a parts table", but that doesn't really tell me what I would need to answer your question directly, so here is a indirect answer.

    Assuming you want a parts list for a particular make, model and year, then my thought would be you need a parent table that holds the make, model and year of the vehicle and then a child table 1:M that holds the parts for that parent.

    If you want it to track an existing fleet of vehicles you might want to get a bit more creative and store your vehicle ID, make, model, year, color ect. in your parent and create lookup tables for the make, model, year,color, trim type ... on and on .... but you would still use a 1:M child table for parts ... you could also use a 1:M child for maintenance records ... trips .. gas purchases ... again .. on and on ....

    Hope this helps you some ...

    Scott

    Comment


    • #3
      Originally posted by Scott Emerick
      Ray,

      You are a bit vague with what type of database you need. I know you said "vehicle application that stores year, make, model as well as a parts table", but that doesn't really tell me what I would need to answer your question directly, so here is a indirect answer.

      Assuming you want a parts list for a particular make, model and year, then my thought would be you need a parent table that holds the make, model and year of the vehicle and then a child table 1:M that holds the parts for that parent.

      If you want it to track an existing fleet of vehicles you might want to get a bit more creative and store your vehicle ID, make, model, year, color ect. in your parent and create lookup tables for the make, model, year,color, trim type ... on and on .... but you would still use a 1:M child table for parts ... you could also use a 1:M child for maintenance records ... trips .. gas purchases ... again .. on and on ....

      Hope this helps you some ...

      Scott
      Scott,
      Thank you for your response, but should I only have one table for this? I think I should have one table for Make and another table for year and model, what are your thoughts?

      Ray
      Kind Regards,
      Ray Roosa
      Raylin Micro, LLC.

      Comment


      • #4
        Ray,

        You still don't get specific on what exactly you need, but here is my thought.

        You will have parts for a 2001 Chevy S10 Blazer so one table that holds "2001 Chevy S10 Blazer" is your parent record which then can be connected to several parts for the "Year, Make and Model"

        Breaking it out to a table for Make and then another for model doesn't make sense to me.

        Why do you think you need to separate this?

        Scott

        Comment


        • #5
          Originally posted by Rayr
          Thank you for your response, but should I only have one table for this? I think I should have one table for Make and another table for year and model, what are your thoughts?
          OK, "R" tells us not to duplicate information, and I presume that's where you get the notion that you should have a table for "make", but is that really true in this case?

          I mean, let's say, you have a table for "Make" as:

          Code:
          Dodge     0001
          Ford      0002
          Chrysler  0003


          And then dutifully, in your parts table, you use "0001" instead of "Dodge". What have you gained? Well, in case you ever need to change "Dodge" to something else, you're set.

          But, of course, that's never going to happen, since you're dealing with past identities. A '72 Dodge Dart is always going to be a '72 Dodge Dart. Now, if you're going to store more information about Dodge (hardly seems relevant for an auto parts app, but hey...) you would definitely want to store it in a different table.

          But even in that case you might arguably keep using the actual Make field as a link ("Dodge", "Ford", "Chrysler") instead of the unique ID because, again, it's never going to change.

          Comment


          • #6
            Originally posted by Blake
            OK, "R" tells us not to duplicate information, and I presume that's where you get the notion that you should have a table for "make", but is that really true in this case?

            I mean, let's say, you have a table for "Make" as:

            Code:
            Dodge     0001
            Ford      0002
            Chrysler  0003


            And then dutifully, in your parts table, you use "0001" instead of "Dodge". What have you gained? Well, in case you ever need to change "Dodge" to something else, you're set.

            But, of course, that's never going to happen, since you're dealing with past identities. A '72 Dodge Dart is always going to be a '72 Dodge Dart. Now, if you're going to store more information about Dodge (hardly seems relevant for an auto parts app, but hey...) you would definitely want to store it in a different table.

            But even in that case you might arguably keep using the actual Make field as a link ("Dodge", "Ford", "Chrysler") instead of the unique ID because, again, it's never going to change.
            Blake, Scott
            Ok so your saying make one table for everything holding year, make, model
            But what if I want to create a form for viewing my info and I want to see all models for ford? this seems easyer if I put the make in a sep table.

            What I am going to do is create a tree control on my form so the user can select ford then under ford they select the model then under the model they select the year, so should I still only use one table or brake it up into two?

            What are your thoughts?

            Thank you
            Ray
            Kind Regards,
            Ray Roosa
            Raylin Micro, LLC.

            Comment


            • #7
              Ray,

              A table holds records which are made up of 1 or more fields. Records can be sorted, filtered, queried based on field values.

              But what if I want to create a form for viewing my info and I want to see all models for ford?
              You filter or query the TABLE to show only the RECORDS which has a value of FORD in the make FIELD

              If you want to see all 1997 Fords you filter or query the TABLE to show only the RECORDS which has a value of FORD in the make FIELD and the value of 1997 in the year field.

              Creating a tree uses the field values as well. Your tree might be set up as Year, Make, Model:

              1997^Ford^Explorer
              1997^Ford^Mustang
              1997^Chevy^Blazer
              1997^Chevy^Blazer, S10

              I hope you understand what I am saying.

              Since it is a small enough application, you can do it this way and also try it the way you think you should have it and see what works for you.

              Good Luck!!

              Scott

              Comment


              • #8
                Hi Ray

                I developed an automotive application several years ago to track the salesman's performance.

                I am not sure as to what you want to accomplish. As stated by others if we know exactly what the end result of application will be and the reports needed we can better help.

                That being said here is what I did.

                The car info associated with the salesperson was in one table. A look up table was created for the cars. This had 3 fields. Make (ford), Type (suv/van etc), Model (taurus).

                I did not include the year in the lookup table. This creates to many entries in the lookup and this information is not relevant for a look up. You only need to enter the year for you car in the info table.

                The look up table was filtered based on fields and values in the info table.

                1. Make field would filter the lookup table for Unique Makes only.
                2. Model field would filter the lookup table showing models filtered by the value in the model field.
                3. Type field would filter the lookup table showing type filtered on Unique types.

                You can also use your lookup table as the Parent in a one to many relationship with you info table for reporting purposes.

                You probably already realize you will need a seperate parts lookup table. Here the year is important and needs to be included. As this will allow you to filter Parts for differenct model years.

                I hope you find this helpful

                Robert

                Comment


                • #9
                  Thank You

                  Thank you for all your help.

                  -Ray
                  Kind Regards,
                  Ray Roosa
                  Raylin Micro, LLC.

                  Comment

                  Working...
                  X