Relationship 1:1

Asked

Viewed 649 times

0

I’m having problems in the relationship of my tables products and stock. The stock table is responsible for storing the quantity of each item in the products table and the date when the product went into stock. Each item in the product table can only be registered once in the stock table. So I was using the following structure:

create table produtos(
id_produto int unsigned auto_increment not null,
marca int unsigned not null,
categoria int unsigned not null,
nome varchar(100) not null,
valor double not null,
descricao varchar(250) not null,
tamanho varchar(2),
cor varchar(15),
sexo varchar(1),
constraint pk_produto primary key (id_produto),
constraint fk_marca foreign key (marca) references marcas(id_marca),
constraint fk_categoria foreign key(categoria) references categorias(id_categoria)
);

create table estoque(
id_estoque int unsigned auto_increment not null,
produto int unsigned not null unique,
qtd int unsigned not null,
datarep date not null,
constraint pk_estoque primary key(id_estoque),
constraint fk_produto foreign key(produto) references produtos(id_produto)
);

The problem is that this way, I can register the same product several times in stock. So, I ended up thinking about some alternatives:

  • Create a field Unic not null to identify the products in the stock table, and consequently prevent the product with the same code to be registered.
  • Use product key as primary key of stock table, but I have my doubts whether this would be a good practice.
  • Join the stock table in the product table through the quantity and replenishment attributes, for example. In this case, I would need to update the table with each purchase and arrival of a new stock.

What would be the best option for this case? If none of them are good practice, what could I do? Obs: I’m using mysql.

  • 1... The id would already be your Unique field, you can use a hash function based on the id to generate a unique hash for each product. 2... With this you would prevent there being more of the same product registered in the stock, I honestly do not see much harm, unless you want to keep a history of when the product entered and when it ended, in this case would be to have a created field_em, and when the product in stock ended up updating a completed field_em with the current timestamp. , in the next reset create a new row in the table.

  • If you already have the constraint fk_produto foreign key(produto) references produtos(id_produto) I don’t see much point in still having produto int unsigned not null unique,

  • Hello, Marcelo. Would you have an example of using this hash? I believe I would need a field to generate and store this hash, correct? Despite having this Constraint, I can still register the same product in stock more than once, so I added this Picnic to see how it would look, but I did not test.

  • You can search for something inside the mysql itself, or use some external tool, when your record is created, get the last_id_insert and use that one library for example, to generate a hash

1 answer

1


In your case, that the relationship of the tables is 1 to 1, I do not see much sense in being implemented separately. It could be all in one table:

Produtos (id[PK], marca, categoria,..., qtd_estoque, data_estoque)

But if you are going to manage the individual items of each Product in stock, then you could have the stock table of the items and the quantity of products in stock could be computed from the table itself by summing the items of that product. Example of a stock table for items:

Estoque (id[PK], id_produto[FK], data_inclusao)
  • I also thought about it, but I would have no problem because the record is always being updated in case of a sale?

  • But what would be the problem?

  • I thought there might be some problem with the fact that I’m always updating a record of this table, I traveled here. Well, now that you mention it, this second option seems to be better, so I imagine I could get a report with the amount of stock and so on, but that would turn my table into a one-to-many relationship, correct?

  • There would be no problems in updating a record constantly . Database is made for this, rs. Yes, your relationship in the second option would be 1 for many.

  • It is. rs. Friend, I think I’m coming to the ideal bank, but I still have one more question, if you don’t mind. This second option is the best because I can manipulate the stock, see when it entered, when it ended and etc, but what would be the question of quantity? I believe I will need this field to identify how many items arrived, but what would be the ideal way? Have the quantity in the stock table itself? or in both tables?

  • SELECT COUNT(*) FROM STOCK WHERE ID_PRODUTO = 1

  • With this you add all the items in stock of the product with id 1

  • Thanks, Marty. I’ll do it!

Show 3 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.