I am planning to start a site in which the content is generated by the users. What is the best method to save the data submitted by user?
Is the method of saving the data in phpmyadmin database a good idea considering that the data submitted by users is large similar to a blog post. Btw I'm good in working with php and mysql but I'm not sure whether it is a good method.
By 'phpmyadmin' database I assume you just mean a MySQL database.
Since your user data is basically a 'blog post' - basic text and HTML, and you'll most likely be storing username, posting dates, titles, and the like as well -- a MySQL database is a fine place to store it.
If you're using standard shared hosting, your options are pretty much a relational database (MySQL) or a flat file. Between those two choices, a relational database is the better option.
Not sure just what you're asking here - If you're thinking of actually trying to save a .jpg file and text as blobs physically stored in the database, don't. Not if you intend to have a lot of users all uploading stuff. Look into saving it on your server in a folder for the user or better yet to the cloud - it'll be cheaper in the long run and save you tons of anguish with a corrupt database.
Related
I would like to know how applications such as Quizlet or Studystack manage all their user card sets that potentially could be very large. If you store the data in a database such as MySQL, wouldn't the large amounts of data eventually make the database slower? And if you are trying to search through the database for a specific key word such as "biology" in which you need to return relevant data to be incorporated into an html page for the user when they click a link, wouldn't that prove to be difficult? Could somebody explain how it works and proper techniques? Thanks.
If you are interersted by Xuggler I maintain a fork and you can use these binaries https://cloudsmith.io/~olivier-ayache/repos/first-repo/packages/detail/maven/xuggle-xuggler-server-all/5.7.0-20210205.154804-12/a=noarch;xg=xuggle/
Here is my fork https://github.com/olivierayache/xuggle-xuggler
I am making a site where user can register and make posts using PHP.
Currently I have 2 tables in a db, and lots of csv files. Both of them together hold, username, password etc. and counters, posts, date etc respectively.
My Question is If it is a good idea to go with two storage systems. Of course i can store all of it in a database. My main concern is fast read & write capability.
Also note that some data is required frequently, and some is required rarely, if i have to divide the data b/w csv & db, what can be better way?
Use only DB, CSV is not for that.
I have at my disposal PHP, MySQL and a Linux server.
The site I'm creating for a client should have a back-end manageable photo gallery.
I am planning to create it fully in MySQL, meaning I would have a table containing a mediumblob that would contain the binary data of the picture. This would allow me to have everything at one spot, not having to rely on the chance that the client wouldn't accidentally remove an image from the gallery directory without updating the database and so forth.
The alternative, of course, would be to have the images independent of the MySQL database, and only save the image paths.
What I'm posting a question here for is to ask you experts if there are any potholes in this method I'm not seeing. I have never tried this method of creating a gallery before. For instance, is it considered bad practice retrieving large amounts of data from MySQL when file-system storage is possible?
What are your thoughts?
(I will mark correct the reply that erases all doubt about this case from my mind)
Personally, I wouldn't recommend you reinvent that wheel... especially if you want your clients/users to be updating this data. Far better to look to an already existing solution. There are tons of them out there. Probably the most robust is Gallery
As for your actual question, there are lots of reasons not to store binary files in the db. (And only a few that I know about to do so.) Size is a definite consideration. Many hosting providers have a much smaller size limit to your database than filesystem limit. You would be tying them to providers that allow enormous database filesizes. Additionally, apache is VERY good at serving static files to the client. PHP passing those binary files through is going to be WAY slower. Your site's speed would definitely suffer.
I would not store images in the database since you probably want to enable client and/or server side caching for those images. Storing images in the DB will not do any good for this. Store the path of the image in the database and not the file itself.
I wouldn't store images in the database, grows you database way too big. I would make references to the images on the file system. Database reserved for meta data on the images in question.
Also curious why you don't just opt for an open source image gallery to start with like ZenPhoto? And build on that for the customer?
So I have a simple Apache with MySql I am developing a PHP app. I have Users Table in my DB. I vant to let them store Icons.
My question Is what's the best way of attaching such data as icons (100-250kb's) to DB - Is it beter to store them Inside DB or store them as File and some how attaching links to icons into DB. What's the best way? Are there any classes that automate this process (of attaching such data to DB)?
I would store them as files, and reference them from the database. I made the mistake of storing images in the database itself (as BLOB I think) and regretted it the next day when db-connections had to stay opened longer, images didn't cache when I went to view them multiple times, etc.
I would only suggest storing the image itself in the database if it's absolutely necessary. If you're going to be using these images frequently, and showing them in multiple placed, I would suggest storing filepaths only in the database, and keeping the images in the filesystem.
Related: Storing Images in DB - Yea or Nay?
easier to keep the icon as a file and store the path in the db
the most efficient way to serve the image is by having the web server transmit a file directly from disk, so you may as well keep it there. having it in the db would make serving take longer and would have little purpose (there's no need to search through the binary data of the image and this would increase the size of each row in the db by a large amount, making read/iteration operations much less efficient because of the reduced locality)
I was wondering what is the best way to store a users upload images like an avatar and so on using PHP and MySQL? Where should I begin? And is there a good article on this?
"Best" depends on what your goal is.
The two primary ways of storing user-uploaded images are either putting the binary content into the database as a BLOB, or storing the images to the drive somewhere and putting an entry into the database indicating which image belongs where.
Placing the images in the database has the advantage of not requiring any sort of filesystem permissions on the webserver, and removes any sort of syncing issues if you're serving up the site off of multiple webservers. However, over time it makes your database huge, and if you don't design your tables correctly, it can absolutely kill your performance and scalability.
Storing the images as file on the file system has the added advantage of making retrieval extremely quick and efficient, since webservers are very good at serving static files.
Edited to add
If you decide to store file content in the database, absolutely do not put it in a table that needs to be accessed quickly. If, for example, you have a "users" table that is searched on nearly every pageview, then that table is not the place to put your file contents. Instead, create a separate "images" or "files" table containing the file and related meta-information.
Putting a lot of bytes per row into a table makes that table very slow to work with. You don't want that kind of thing in tables that see heavy use.
Images should really be stored on the file system for a couple of reasons:
Proxying and If-Modified-Since web requests: Apache can process If-Modified-Since HTTP headers for you and return a 304 response, and that's about the best performance you can get. Reverse Squid proxies and proxies posted at ISPs will attempt to take advantage of this.
Virus scanning: if you allow any file uploads, jerks will try and upload scary stuff to see if they can bust your site. It's not unreasonable to want to run ClamAV or the like against your user uploads to see if there's trouble afoot. You wouldn't want to tie up your database if you wanted to scan the records for malware.
Schema simplicity: If you allow file uploads, you'll also need to add meta data about the MIME-type, file size, height and width. If the file itself doesn't match the MIME-type in the table, then you need to code a select from the table and stream it into /usr/bin/file. It can be much simpler to shell_exec( "/usr/bin/file /path/to/mumble" ).
Thumb-nailing: user image uploads are likely to need to be thumb-nailed, and this is often much easier done asynchronous to the actual web request. It's really not fun when some well meaning user attempts to upload a 150MB photoshop file given to them by their professional photographer buddy, and your apache instance goes OOM when attempting to load the ImageMagick library in the memory space of the web worker. This really doesn't scale for apache workers. Create a work queue/cron job outside of Apache to handle this work.
Table corruption: Wow, you don't really want to cripple all user avatars if your MySQL index file gets borked and you need to do an offline table repair on that table.
Backup and restore: You don't really want to lock a large table with mysqldump. Using rsync will save you a lot of time and give you much more flexibility. Tables are typically restored a whole table a time--tables are not typically backed up in smaller pieces.
make a new directory on your server for each user with the user id being the name of the directory and save the user's images inside it. whenever you want to display the user's image:
<img src="<path>/users_images/<user_id>/thumb.gif" />
If I were you, I would just save the image somewhere in your sites directory and then save the link to the image in MySQL, if you really want to save it in a database, I would read it into a string and then base64_encode() it and then save it in the database.
There are all sorts of little troubles you will face by storing them in a database, you will have to create scripts to echo them back out ect, and the server and database load will be greatly increased. If I were you, I'd just store the reference.
I suggest having a table where you store user data like username, first name. In that table create a field called something like "avatar" in which you can store a file reference.
Assuming your user avatars are stored in: htdocs/images/avatars/
And user apikot has the avatar "avatar.jpg" stored agains it's user in the database, you could then compile the following url when generating an image tag: "/htdocs/images/avatars/avatar.jpg".
Here's an example of storing the image in binary on a MySQL database. I'm not too sure if there are any advantages or not to that. I'll leave it for someone else to comment.
Another way you could do it is store the location of the image in a column and query it for referencing.
Create a BLOB type field, and insert the result of file_get_contents( $ImageFile )