Alpha Video Training
Results 1 to 8 of 8

Thread: Design considerations help

  1. #1
    Member
    Real Name
    Steve Pick
    Join Date
    Apr 2000
    Posts
    340

    Default Design considerations help

    In reviewing Alphasports I noticed that the extension price was a field in the table rather than a calculated field on a form. Up to now, I have thought that the calculated field for a form or a report was the prefered design. It saves a little in storage. Anybody have any strong views?

    Also, I note a similar situation with the "ship to" check box. I don't readily see the design purpose and it doesn't seem to be used to speed up data entry.

    On the "ship to" issue the design requirements have to cover various real requirements (at least for my business).
    1. Ship to customers address (ie bill to and ship to the same)
    2. Ship to address is different from bill to address.
    3. Customer has more than one ship to address.
    4. Customer wants it drop shipping to a third party.
    5. Customer wants it drop shipping to a third party who is another of my customers.

    From the above, my inclination is not to have shipto and billto fields in the customer table but to add each seperate address to the customer table and use a memo field to indicate which of the conditions 2-4 the entry is for, when it is not 1 or 5.

    The invoice has a shipto field which is populated by the appropriate customer id field, with the default value set to that of condition 1 above.

    Currently, the above requirements are only implemented in Alpha Four but as I struggle to move to A5 I was wondering if I need to make any changes in the design to the tables.

    Steve

  2. #2
    "Certified" Alphaholic Keith Hubert's Avatar
    Real Name
    Keith Hubert
    Join Date
    Jul 2000
    Location
    London, UK
    Posts
    6,930

    Default RE: Design considerations help

    Steve,

    " I was wondering if I need to make any changes in the design to the tables."

    The answer is yes. Alpha Sports is only a guide to be learnt from. It is not the whole of what Alpha can do. The hard part about Alpha is stretching your imagination into all the things Alpha can do. I am still learning and enjoying every moment.

    Keith Hubert
    London.

  3. #3
    Edward F. Schulz
    Guest

    Default RE: Design considerations help

    Hi All,

    I prefer the "bill to" and "ship to" to be separate tables.
    efs

  4. #4
    Member
    Real Name
    Barry Rochford
    Join Date
    Apr 2000
    Posts
    452

    Default RE: Design considerations help

    Steve, when you can have a 60GB hard drive, a few extra bytes doesn't amount to a hill of beans. As for the ship to address, bill to address - there is no DATABASE POLICE! Do it the easiest way always remember KISS (Keep it simple stupid). Then it's easy to modify if required.

    -Barry

  5. #5
    Member
    Real Name
    Barry Rochford
    Join Date
    Apr 2000
    Posts
    452

    Default RE: Design considerations help

    Incidently, I would definitely NOT consider using a memo field for the addresses.

    -Barry

  6. #6
    Member
    Real Name
    Steve Pick
    Join Date
    Apr 2000
    Posts
    340

    Default RE: Design considerations help

    Barry,

    The memo field would not have the addresses. It would say something like -" Smith's customer. See invoice # 4678".
    In looking down my customer lists I need to know my customers and if there is a name I don't recognize then the note is a help. It is impossible to provide all fields in a customer table to keep track of all the data on a customer. A memo field covers these shortfalls.

    Steve

  7. #7
    Mark Campidonica
    Guest

    Default RE: Design considerations help

    The above is a very common use of memo field.

  8. #8
    Member
    Real Name
    Blake Watson
    Join Date
    Jan 2003
    Posts
    961

    Default RE: Design considerations help

    In reviewing Alphasports I noticed that the extension price was a field in the table rather than a calculated field on a form. Up to now, I have thought that the calculated field for a form or a report was the prefered design. It saves a little in storage. Anybody have any strong views?

    If the data is "dead", that is, a record of something, like the amount paid, make it a field.

    If the data is "live", that is, it is meant to reflect a process that may change, make it calculated.

    Invoice info is typically "dead".

    For example, the sales tax in your state may currently be 6%. When you issue an invoice, you want the tax at that moment. When the tax goes up to 6.5% next year, you don't want old invoices showing different values.

Similar Threads

  1. Set Design
    By paulyp in forum Alpha Five Version 6
    Replies: 1
    Last Post: 08-17-2004, 06:50 AM
  2. CRM Design
    By techiemark in forum Alpha Five Version 5
    Replies: 3
    Last Post: 07-15-2004, 11:18 AM
  3. Design help
    By John Dodson in forum Alpha Five Version 5
    Replies: 5
    Last Post: 04-13-2003, 05:52 PM
  4. Can't go to design
    By russ Boehle in forum Alpha Five Version 5
    Replies: 10
    Last Post: 10-30-2002, 05:40 PM
  5. Help with Set Design?
    By Tom Sullivan in forum Alpha Five Version 4
    Replies: 2
    Last Post: 04-03-2000, 12:17 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •