boolean vs. more specific variables

In trying to create better, more consistent conventions I wanted to get feedback on the following options. The scenarios I'm using involved recording whether an item is shipped to an existing address or a new one.

Both of these setups would get the point across, but are their additional pros and cons I'm not thinking of, or conventions on w开发者_JAVA百科hich is better?

    field name: ship_to
       option 1: new_address
       option 2: existing_address

Pro: 
- Allows for new options down the road if needed.
- Easier to grasp what's going on when looking just a the database

Cons: 
- Not easier to grasp in the code - have to remember the options



    field name: ship_to_new_address
       option 1: true
       option 2: false

Pros / Cons - Pretty much the opposite of what I listed above.

The answer is neither.

You mentioned database which I will assume means Relational Data Base Manager. Your design does not follow the one-zero-infinity rule and will require modification to support another ship-to address at the least possible convenient time (like when the customer is screaming).

A proper data structure is:

1. a Customer has infinity orders
2. an Order has a Ship-To address
3. there are an infinite number of Ship-To addresses

Where Customer, Order, and Ship-To are all separate database tables. This is known as Third Normal Form and has been standard practice since at least before 1970.

If you need to note that an order has a non-standard Ship-To address, record that boolean in the Order.

What is the business need? Are you trying to indicate the shipping address has changed? Are you trying to differentiate between a new address or existing address?

Then, why do you care? You have to indicate so you save the address to a database if new? You need reporting on how many people shipped to a non-existing address?

Finally, can you ever end up with more than 2 options (new, existing)?

The answers to the questions will indicate the proper direction. My personal preference is to use Boolean if there are only two choices and I see no need to ever expand. But, I deal a lot with external APIs, so change requires a lot more thought than an option that is internal only. An enumeration (which generally will be stored as a "type table" in a database) is fairly efficient, perf wise, and not too heavy in storage, so it is not a bad option.

There is a third option:

• Put addresses in a table of their own (probably with an owner column linking back to your user/account table).
• Use a ship_to column that points to the address table with a foreign key.

Pros:

• Each person can have as many addresses as they need (home, office, cottage, friends, ...).
• Nicely normalized.

The only con I can think of is that you'll have to do more joins but joins aren't really a bad thing. You may need a bit more sanity checking to make sure all the ownerships line up nicely but that's not a big deal either.

It all depends on what you're trying to accomplish. If all you want is to know if the item is shipped to a new address or not than the boolean is OK.

I think you need to think how to make your architecture scalable. Like you said in the first "pro", you might want to have more options like "temporary_address". If you want more deterministic variables you can always use an enum.