1
I am making a register of stores in a classified site, where the user would pick up the address of the store through viacep and along with the data would give an input in the bd.
table "advertisements" would look like something like:
id | name_place | usuario_id | zip | street | neighborhood | city | number | data_send | image | categoria_id
This modeling is correct, since I can contain many columns, not to mention the number of entries this table can have. Aiming performance.
But it would be possible to reuse this address data if someone else registers a store in the same zip code?
And if I separate the address data into another table, is that viable? I wanted to have more control in this data, to be able to give a description to the city, to make a search more optimized by cep and etc. Only that worries me, if the user updates the registration of their store and changes the zip code that can have several stores.
Give me a light, for the text note that I am well lost.
All answers depend directly on the requirements of your application. You have already made the list of requirements?
– Woss
Not necessarily, I need to know the best method taking into account the performance of this type of registration.
– Be'lakor
Performance at what points? Speed or memory?
– Woss
Speed, quick check-ups. My question is whether putting all the data corresponding to the address in the table with the ad data would not slow down these queries. And if it were possible to reuse addresses.
– Be'lakor
The amount of data will impact much less than making the bank well structured. I recommend you read on bank normalization, This will probably answer this and possibly many other questions you have. If you leave it the way it is your table will not be normalized, because it has address data associated with user data. Not always this is bad, depends on the requirements, but anyway it will not be possible to reuse the zip code, because it depends on the user id.
– Woss
Tip: Do not take the zip code as a fixed reference. The CEP bands are constantly changing and can be changed several times to the same address. If your bank is not consistent, you may even have duplicate Zip Codes with different addresses.
– Woss
I did a brief reading of the article (I will study it later). It would be correct to create an address table and link with "address_id" in the local table, being unique for each location. Repeating the address in this table will not be wrong as long as it has a unique id. Correct?
– Be'lakor
A table that calls
anunciosand there’s an address that sounds wrong. I can’t guarantee because I don’t know the problem, it’s not clear. It gives room to consider that it’s opinion to talk about it, but I still think it’s unclear. Having too many columns or rows is no problem, I don’t know why people care about it. Then it should model differently p/ stay + correct, we just have no way to state how without deeply understanding the problem. I almost closed as not clear,but I ended up opting out of scope because on the sites we solved specific problems,give a light is not in the scope.– Maniero
I thank Maniero, really, I could not pass my thought, but his reply like that of Anderson reassure me as to the number of columns. The solution that I found with your answers is that I will make an advertisement table and another address, and I will register the advertisement along with address, then I will reference with a field in the advertisement table, and that address will be unique for each advertisement even if it has the same name. Thanks for the help.
– Be'lakor