A table just to store images or split by types?

Asked

Viewed 63 times

0

I want to register users, where they should put their profile photo and inside the program, store other images, I better make a table only for all photos or split for each type?

I saw some places saying it’s better to make a single table for everything, but without giving too much a reason why!

  • 1

    If you have a set of images, including the profile photo, related to the same user you have to check if there is any justification in your project to need to separate the profile photo from the other images. In terms of database there is no reason to separate.

  • @anonimo understood, in terms of the project does not have a justification, what I was thinking was if separating would help in the efficiency of the bank and etc. Thank you very much for the help!! I guess I’d have no problem doing everything together anyway!

  • Early optimization is the mother of all evils. Do your project and implement it. If during the tests you find that there is a performance problem then study the most used queries and evaluate if some kind of table division can optimize them.

  • @Arthuroliveira Did the answer solve your question? Do you think you can accept it? See [tour] if you don’t know how you do it. This would help a lot to indicate that the solution was useful to you. You can also vote on any question or answer you find useful on the entire site.

1 answer

3


This shape can be interesting in most cases as optimization. In general you need the user data in various contexts but not the photo, so it may be that having only the data can read several of them in a single access to the storage medium that is usually quite slow. If you have everything together it is likely that each user will cause at least one access, even if you do not take the photo(s)).

But I am speculating, it may be that Postgresql has an optimization that does not cause this effect, then I do not see much advantage. In fact without knowing the actual implementation of Postgresql can not guarantee anything, everything can happen, so always need to test.

For example, it would be possible for a user access to be curled in the memory with photo because it is together, and occupying more space in the memory could affect the overall performance because it has less curly data. I doubt this will actually happen, but it’s a possibility.

It may be that Postgresql has a specific motivation, some database systems are even bad for putting images inside it. With a reference to the location that stated this could help give a more precise answer.

From the conceptual point of view there is no problem at all together, by optimization it can be very interesting to separate.

  • My question is the following, I have a table of users, and these users will add 1 profile photo, at the time of registration, and while using the system, they could add other photos, for example, food image. The profile picture would only appear on his profile, practically, and the food photos, would be posted on a common page where other people would have access. I wondered if it is good practice to separate these two types of image (profile and food, for example), or if I can only make a table for all images.

  • 2

    I answered why we use one thing or another, saying what’s best for you is not something we respond to here, because we never have enough information for it. Motivations teach you something, tell you what to do, no. Research good practice here on the site, especially what I talk about. Forget this business of good practice, it doesn’t solve anyone’s specific problem.

  • Yes, of course, and you really answered what I wanted, the reasons for using one or the other, has helped me a lot, and it certainly motivated me to study more about. What I think is that maybe if I was separated by types, the table wouldn’t be so full, and so the search would be faster, but I think the amount of data to do this would have to be very large.

  • This just testing, properly.

Browser other questions tagged

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