There can be 100k+ records in products table. Each product may may have around 100 images (because product may be multi-variation) and each image has thumbnail created programmaticaly. Thus, we got (100k+ product) * 100 * 2 = 20000k+ images.
Thus, I want to have best practice for storing and managing these images.
I have two solution:
creating main folder for product and creating some structure inside that product. Only save main product path at the products table.
products/product_1/images/folder_1/main.jpg
products/product_1/images/folder_1/thumbnail.jpg
products/product_1/images/folder_2/main.jpg
products/product_1/images/folder_2/thumbnail.jpg
I have applied this solution. It becomes tricky when editing product.
creating media database table and storing all paths there. This is easy setup.
But I concern about performance.
So which is the best solution or there are other ones ?
I think that you should try storing it in database with 1st option. And your question about the thing where after editing product it becomes tricky and messy, I think that you should use some sort of Id of the product to set the path so that changes in names and other properties wouldn't affect the path of product.
Also, second method would become messy because **a product has multiple images and managing all those images in a single folder and if editing names it would result in many editing in database to change paths and names etc.
Related
I am developing a health care system and I want the doctor when starting to type a diagnosis instead of typing it , he can select from a list that will be displayed for him.
the list contains diseases or symptoms that will then be inserted into database in a diagnosis table.
I did that because of two reasons:
I want all doctors to use the same list of symptoms when writing their diagnosis to work on that data later on, instead of each one typing his own way.
The data will be localized and translated to different languages when displayed to different regions.
I am facing a problem here, should i put all these in a lookup table in a database or a config file ? given that number of rows are 3000 in 7 languages ( each language will have it's own column ) and i may at anytime add new data or remove.
I would put them in a database. I find it easier to maintain, and faster to query than a config file.
I'm building an app the attach multiple pictures to a recording. Hence, there is a "Recordings" entity with attributes "Name" and "URL". I want to attach multiple images to one recording.
So do I add another attribute "images" and store array of images? If yes, how is that possible?
Or do I create another Entity that has attributes "Image" and "RecordingID" that has all images of all recordings and each image is connected to it's recording with with the recording ID? If yes, how do I create a unique ID for the recordings?
Please answer which one is better performance wise, and with your choice explain its associated question.
It depends on how you use the data, as always.
If you use an array of images, Core Data will load all of them as soon as you need one of them. You'll either have every image in memory at the same time, or none of them. If you'll always use all of the images at the same time, this might be OK.
If you use a separate entity, you can load individual images when you need them. It's slightly more complex but can reduce memory requirements. It also makes more sense if you decide you need more metadata for each image, for example a creation date.
In both cases you'll be better off saving the image to a file and putting just the filename in your persistent store. It's usually best to keep binary blobs like images and sounds out of Core Data. Binary is OK if you know the value will be very small, but images can potentially be quite large.
I'm not sure why you want a unique ID in the second case where you don't use one in the first case. If you need a unique ID for some reason, the UUID class is a convenient way to generate one.
I've recently come across this idea that separation of data manipulation logic fully in the SQL code would result in a performance gain, but I'm unsure to what extent this is true and for that reason I'm posting this question.
Assuming that we have a database (let's say a small gallery) in which we have galleries, photos, and tags. Each photo can be member of many galleries, and each photo or gallery can have many tags. I create a single stored procedure for handling photo and gallery management (i.e. PhotoCreateOrUpdate) that can accepts an array of galleries (in serialized text, i.e. GalleryA:Info:Tag1|Tag2), photo information, the same for photo tags, and an array for galleries or tags to be deleted when updating the record. If gallery exists, relations will be added, else they will be created, and same for tags and other things.
I've decided to do this instead of relying on Entity Framework because I believe that this way I can send only one request to the database from the Web-End and this can result a performance gain as I avoid a lot of foreach loops and certain joins can be done faster.
However, when deserialzing the formatted texts, I have to use Cursors a few times which would be equal to the loops when using Entity Framework.
I also think that another advantage of this approach would be to segregate concerns into their own context and keep the ASP.Net code clean.
I want to know to what extent my assumptions are true and this is the point of the question.
I'm building an application that contains a database of movies. Movies have various fields such as a title, directors, actors, etc. I also want to include a movie cover with each row in the movies database. I currently have a column in my database called "cover_path" which contains the absolute file path to an image (the movie cover). I will similarly have one called "movie_path" which contains the path to the actual movie.
Are there better ways of storing files in a database and by storing the file path to an image in the database am I defeating the purpose of data independence?
Using file paths have more advantages then storing binary data in the database. This is a good discussion on this subject.
Though I'm not sure in which way would this defeat the purpose of data Independence on any level.
I'm writing an application that will have a SQL Server backend that will store (among other things) urls. URLS will be mapped to users, and some URLs may be common between different users. In absence of a true DBA, I'm trying to design a solution that can handle hundreds of thousands of URLs as efficiently as possible.
Ideas:
Create table that simply has ID, URL
Pro: simple, complete.
CON: duplicate entries for a URL will exist which will cause the table to be larger than it needs to be.
Break up the user and URLs into separate tables. One table containing USER ID, and URL ID . Another table with URL ID and URL itself.
Pro: single URL in the system, seems more "enterprisey"
Con: must join two tables when trying to pull back results, and not really sure what the benefit of this approach is?
Expand on the 2 idea, except REALLY break it up. So have a table for domain, another for path/query string. Then, user table would have userid, domain ID, path ID.
Pro: urls could share data even if it was unrelated (meaning, cnn.com/helloworld and nbc.com/helloworld would have different domain ids, but same path ids.. seems this could be useful when running metrics later?
Con: Seems like a nightmare from a performance perspective (again, because joins would be necessary to pull a URL.
Any thoughts?
I would do the following in my design:
UserId UrlId
1 1
2 2
1 1
UrlId Url
1 http://www.google.com
2 http://www.yahoo.com
Storing your URLs in a seperate table and only creating a new entry in the URL table, if an exact match does not already exist. If you have a lot of common URLs, this will save some space. You could take it a step farther and add a third table as you mentioned, e.g.
UrlPathId UrlId UrlPath
1 1 /shopping
...and then tieing the UrlPathId to the User table. And perhaps even further:
UrlPathId UrlId UrlQueryString
1 1 ?product=speakers
...and again, referencing this from your User table.
It sounds like you are describing a many to many relationship between users and URL's.
I would highly suggest ruling out option 1. Not only will this increase size, but because if you need to update a URL or a User, you'll have to do it every time that it's duplicated, instead of once.
Choosing between 2 and 3 is more difficult, because it depends much more on how this is going to be used. #2 is a lot more simplistic, and is still normalized. The features in #3 don't seem to outweigh the complexity to me, so personally I'd pick #2.
Edit: Upon seeing George's answer, I completely agree with the first section.
Are you really that short on space? Unless you need to treat URLs as an object in their own right I would just go for option 1 and cover it with indexes if you have specific performance requirements on URLs alone.
See my other comment here on dealing with orphan URLs.