is it recommended for creating each folder for each user to store the image uploaded? or should i just create an image folder and put everything inside?
Note: for web application such as ebay where each user will not have a a lot of image uploaded, but they might be millions of users using it.
There are other considerations to decide whether to create a folder for each user or
just a big image folder containing all images.
What is important? Ease of maintenance? Performance? Any Resources limitation ?
Will you ever need to persist those images?
What are the operations you will normally perform on the images?
How often?
Having a folder will be more organized, but you may need to maintain millions of folders and it will require more resources.
It will be difficult to maintain if the images are not followed any naming convention based on the user id or name if you put them in one single folder.
Before you decide which way to go, you need to look at the overall operations.
Related
I am working on automating the translation workflow and improving the Localization process as a whole of a Rails website. I am using SimpleBackend so only YAML files are used for storing translations.
The current locales directory consists of folders, then sub-folders (in some cases) and those sub-folders containing yml files. I am considering to integrate the project with some third-party tool like Transifex for translation management so may be using a single YAML file for each language may be good for management of workflow.
If someone can highlight the pros and cons of both structures then it would be really helpful to decide whether I should switch from nested file structure to single file pattern or not. Also, the project is an Open-Source project with active contributors and so thinking for a long-term solution.
Thanks!
I think whatever tools you are using to make the process flow smoothly factors a lot in this decision. You should explore how exactly Transifex wants things to be structured in output, and try to keep your current input structure, and give that a shot before making a decision.
However, in my opinion, for a large app with a lot of translatable text, my preference would be to allow for multiple yaml files in your default locale, and one or two consolidated yaml files for each foreign translation. If there isn't a lot of translatable text in your app, maybe a single file is fine for you, but given it's already split up, there's a good chance that's the better choice. On a team with many contributors you can end up with a very high churn file (maybe with a lot of merge conflicts) that everyone changes all the time.
Splitting into separate files lets you logically separate out text to match a domain in your app, like a separate yaml file for mailers (or even each mailer), and one for each domain (or controller). Either way, it puts you in control of your organization strategy.
However, there isn't a lot of value, IMO in separating your foreign translations to mirror that structure. The systems I have experience with (not Transifex) generate your foreign translation files for you, so you just need to sync with the web interface and commit the results.
I have a very small e-commerce website(not launched yet). Requirement: users need to be able to change image and text content only (not the price). Images and text are saved in a folder at the server (no database for images). Based on my research, I still have not got better idea than possibly creating a WCF Restful service!! My Code are in GitHub and project is hosted in Azure. I am using ASP.Net, MVC-5, RESTful, OData.
Please suggest me possible best approaches with reasons, if you could.
Images and such are considered a BLOBs (Binary Large Object). Best practice for storing those on Azure is to use Blob Storage.
You can find step-by-step tutorial here:
How to use Blob storage from .NET
Next time when you deploy your solution, it will not override images and texts, since those will not be in solution folder.
On the iOS filesystem, is there a way to optimize file access performance by using a tiered directory structure vs. a flat directory structure?
Specifically, my app has Objects that each contain a number of images and data files. A user could create thousands of these Objects and I need to optimize access to one image for ~100 arbitrary Objects at a time.
In this situation, how should I organize files on the filesystem? Would a tiered directory structure be faster than a flat one? And if so, how should I structure the tiered system (i.e. how many tiers, and how many subdirectories / files per tier)?
THANKS!
Well first of all you might as well try it with a flat structure to see if it is slow or not. Perhaps apple has put in code to optimize how files are found and you don't even need to worry about this. You can probably build out the whole app and just test how quickly it loads and see if that meets your requirements.
If you need to speed it up I would suggest trying to make some sort of structure based on the name of the file. You could have a folder which has all of the items beginning with the letter 'a' or 'b' and so on and so forth. This would split it into 26 folders which should significantly decrease the amount of items in each. Depending on how you name the files you might want a different scheme so that each of the folders had a similar amount of items in it
If you are using Core Data, you could always just enable the Allows External Storage option in the attribute of your model and let the system decide where it should go.
That would be a decent first step to see if the performance is ok.
I am developing a web application to accept a bunch of text and attachments (1 or more) via email, web and other methods.
I am planning to build a single interface, mostly a web service to accept this content.
What design considerations should I make?
I am building the app using ASP.NET MVC 2.
Should the attachments be saved to disk or in the database?
Should the unified single interface be a web service?
Pros and cons to using web services to upload files
as with any acceptance of files i'd be checking them for viruses or the like. i'm very nervous about files transmitted from the internet.
i always like putting my files in a database because it's neater i find. i hate having files over the network with folders needing rights etc. i know there are people that prefer it the other way so i guess my answer is also depends on personal preference.
i like the db approach because i can more easily tie files to records and do searches. if you have a file system then you still need to store info about the file plus the extra work of storing it.
then if you need to move files around you also need to possibly modify references in the database.
then again, you need to allocate enough space to grow the database and then cater for multiple databases perhaps as storage runs out.
so i guess if you're downloading large files then yeah maybe i can see the point of a file system as it's easier to grow it. if you have small text files then maybe a database will work.
I want a user to upload multiple images (+ thumbs) and give a description about their pics.
What do i need to do to create this the ruby way?
Do i manually create the tables (and which are these) or what gem do i require?
I want to store the file physical on a path and store the link (+ attr. information) in the db (if it is the best solution).
I am open to any alternatives to seek my best solution! :-)
Look at paperclip. Other great solution for handling multiple images for an item is paperclippolymorph
I'm not sure if there is a "best" solution, whether or not you store the images in the database is a tradeoff. Storing images on the server's filesystem and keeping the file's path information in the database will keep your DB smaller, but it will also add one more folder/location that you need to keep backed up and can provide security problems (if the image storage folder is not properly secured, it can be easier for an attacker to pull images off of a filesystem than extract them out of a database).