Grouping total sales by payment type

  • > Are you saying I should have a 3rd table to store the payment types for an invoice instead of fields in the sales table?

    Yes, exactly.

    And ths is actually relational model requirement.

    What if there were 2 cash payments?

    How you gonna handle this in your model?

    _____________
    Code for TallyGenerator

  • Sergiy,

    regarding payments, almost anything can happen. I know that sometimes the cash attendant in a shop enters wrong amount when performing the card payment, and client pays the difference in cash... so that there are two payments to one purchase in shop, one by card, one in cash.

    In any case, I agree with Sergiy and Jeff that the design is first thing what should be changed. 

    Adding new payment type would require adding a new column to a table - maybe to several tables - that's the first thing that signals something is wrong. Even if you don't know much about normalization (and you should...), this should be enough to alert you.

    Another thing is that payment in cash and by credit card are two separate payments (although belonging to one transaction), and they logically belong into separate rows.

    Third table holding payment types is precisely what you need.

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply