Question

I have a question regarding primary keys in Relational Databases. Let’s assume that I have the following tables:

Box

• id
• box_name

BoxItems

• id
• item_name
• belongs_to_box_id (foreign key)

Let’s also assume that I intend to store millions of items per day. I would probably use bigint or a guid for the BoxItems.Id.

What I was thinking, and I need your advice on that, is instead of Bigint Id for the BoxItems, use a sequencial TinyInt number and what identified each item is the combination of the belongs_to_box_id plus the tinyint row (e.g. item_numner).

So now instead of the above we get:

BoxItems

• belongs_to_box_id
• item_sequence_number [TINYINT]
• item_name

Example:

Items.Insert(1,1, "my item 1");
Items.Insert(1,2, "my item 2");

So instead of using bigint or GUID for that matter, I can use tinyint and save a lot of disk space.

I want to know what the cons and pros of such approach. I am developing my app using MySQL and ASP.NET 4.5

Answer 1

When you think about it, there’s really not much difference between the “box/contents” problem and the “order/line item” problem.

create table boxes (
  box_id integer primary key,
  box_name varchar(35) not null
);

create table boxed_items (
  box_id integer not null references boxes (box_id),
  box_item_num tinyint not null,
  item_name varchar(35) not null
);

For MySQL, you’d probably use unsigned integer and unsigned tinyint. There’s no compelling reason for a database to avoid negative numbers, but developers should lean on the Principle of Least Surprise.

Make sure 256 values are enough. Getting that wrong can be expensive to correct in a table that gets millions of rows each day.