I want to display an HTML page at a later date from the database by the user just having to enter the ID of the page.
Is there a better way to do this than just saving it as text in the database?
Thanks!
Storing huge chunks of text (especially markup) in a DB tends to come with a host of annoying problems. I would instead just store the name of the file in the database and store the actual file on the filesystem.
You could store the actual useful information from the file in the database.
Like the title of the page and the content for each section of the page, and then render it using a template from on the disk somewhere. This means you can abstract all the information that is the same from every HTML file and save disk space too. (Its a small bonus though, it might be simpler to do as the other answer suggested and just save the file name in the database and have the file on the filesystem.) Having the information in the database itself might mean it will get backed up with the database, which might be useful to you. Who knows...
Something like flatpages from the django framework. https://docs.djangoproject.com/en/dev/ref/contrib/flatpages/?from=olddocs
Related
I have a simple image upload form. When someone uploads an image, it is for a football pool, so there always is a $poolid that goes with the image they upload.
Right now, I am naming the uploaded image using the poolid. So for example, if someone uploads an image, it might get named P0714TYER7EN.png.
All the app will ever do is, when it outputs the football pool's page, it will check to see if an image exists for that pool and if so, it will show it. It checks like this:
if (file_exists("uploads/".$poolid.".png")) { //code to show it }
My first thought when planning this was to add a field called "image" in my MYSQL database's table for all the pool information (called pools) and I would store a value of either the image name (P0714TYER7EN.png) or empty if there wasn't one uploaded. Then I would check that field in the database to determine if an image exists or not.
But I realized I don't really need to store anything in the database because I can simply use the PHP file_exists check above to know if there is an image or not.
In other words, it would seem redundant to have a field in the database.
Everything works doing it this way (i.e. NOT having a field in the database) but I'm wondering if this is bad practice for any reason?
If anyone feels that I should absolutely still have a field in the database, please share your thoughts. I just want to do it the proper way.
Thank you.
The approach could depend a lot on what exactly you're trying to do. Seems like the options you would have is:
File System Only
Benefits would be the speed of accessing static files of an image and use of it in your HTML directly which makes it a more simple solution. Also if you're comfortable with using these functions it will be faster to finish.
Drawbacks would be that you're limited to using file_exists and similar. Any code to manage files this way has to be very specific and static. You also can not search or perform operations efficiently on this. In general relying on the file system alone is not a best practice from my experience.
Database Only
Benefits, you can use Blob type as a column with meta data like owner, uploader, timestamp, etc. in the same row. This makes checking for existing files faster as well as any searching or other operations fast and efficient.
Drawbacks, you can't serve files statically using a CDN or even a cookie-less subdomain or other strategies for page performance. You also have to use PHP and MySQL to generate then serve any images via code rather than just referring to the image file directly.
Hybrid
Benefits, basically the same benefits as both above. You can have your metadata in MySQL with a MD5 hash and location of the file available as well. Your PHP then renders the page with a direct link to the file rather than processing the Blob to an image. You could use this in conjunction with a CDN by prefixing or storing the CDN location as well.
Drawbacks, if you manually changed names of files on the server you'd have to rely on a function matching hashes to detect this, though this would also affect a File System Only that needs to detect a duplicate file potentially.
TLDR; the Hybrid approach is what you'll see most software use like WordPress or others and I believe would be considered a best practice while file system only is a bit of a hack.
Note: Database only could be a best approach in specific situations where you want database clustering and replication of images directly in your database rather than to a file system (especially if the file system is restricted access or unable to be modified for any reason, then you have full flexibility on the DB).
You can also use the blob datatypes from mysql. There you can save the image as binary data next to the data about the football pool.
So when you want to load an football pool you simple fire an sql statement and check if it returns a result, if so load the image from the database and display the data, otherwise throw an error.
If you have very frequent access you can simply put the images into a seperate table and load the image independent of the data about the football pool. Additional set some cache headers on the image and put it in a seperate file, this way you could simply save the primary key of the images in football table. Then you want to display the web page you simply load another document, pass it the primary key of the image, there the image will be loaded, or if the browser has it in cache, will load it from cache without querying the database.
This way you also have a better consistency of data and images.
Your uploading an image to specific folder and that too with poolid which will be unique. It should work just fine.
Problem :
The code you have written works great. But the problem is, for the first time if the image loaded is .png and second time loaded file in jpeg or jpg then file exists wont check that and hence it may fail.
Caution :
If you have already taken a caution to check that the image uploaded must and should be png than the file_exists will work great.
Alternate Solution :
In case if your not checking for the image type to be .png then I highly advice you to take a boolean image column in your table by is_image_uploaded or something which can be set once you upload the file every time.
This makes sure that in case next time you wan to upload the image then you can directly go and check in your database table and see that if is_image_uploaded column is set or not. If not set then upload or else ignore or do whatever you want
Ok so my problem here is that I have created a page with a table. this table can be cloned infinite times and data is inserted or manually, or from data fetched from a sql table. This means each table created is different.
The point of this page is for users to create their own personal tables, and then be able to save the current page on a specific sql table so they can head back to it whenever they like and therefor load it back to its saved state.
This means each user will have used the same table, but each users tables will have different values in it!
I have very little knowledge in php and have just recently started to use jquery. My question is how can I work out a way to copy the current html page state, and save it to a specific sql table?
This php grabs everything inside <html> and </html>.
<?PHP
echo "<button class=\"Button\" onclick=\"console.log(getPageHTML());\">Print all html</button>";
?>
so far so good. How can i now save this to a sql table? Php will be needed but how?
Hope all this was clear enough.
Help would be great on this one. Thanks
The getPageHTML() is executed on the client's side, so you have to upload it to the server again, where you will have to save the state into your database.
Things you need:
a structure to save the table in the database
knowledge of GET (POST would be better) or AJAX (best) requests
minimal SQL knowledge
You could also save the data to a static file on the server (but don't forget to prevent them from overriding someone elses table).
My idea:
button uploads only table to server
server checks for content size (eg. <=1KB)
server creates hash (best would be SHA512)
server saves the file to .html (with a header and footer to surround the table)
send the user the link to the site
links:
https://en.wikipedia.org/wiki/Http#Request_methods
http://www.tizag.com/phpT/postget.php
https://en.wikipedia.org/wiki/Json
That project could take a while to realize ;)
EDIT:
You could give the table an id (<table id="someusefulid">…</table>) and then use JavaScripts document.getElementById() to retrieve its HTML.
Have a look at this site. It has plenty of examples. First of all look at the basics of JavaScript's DOM to be able to access the table, then try to upload it somehow (preferably AJAX, which is a bit more to study) and after that you can get to the PHP code.
But do always remember, if you read or write files using PHP, be extremely cautious.
I am creating an application where users will post texts. Currently I am creating the text files of that texts post but i am not sure if storing it to MySql table is good or creating a txt file is good. .
Note:
1) There is no limit of the size of text post. Users may post a very big text or user me post containing only a letter.
2) There is no limit of post a user can upload.
Please Help
Thank You. .
Saving data into a file is more cost operation rather than in database.So its better to go for database.Because saving in file will do IO operation and this file I/O operation is really very costly in terms of computation and from OS perspectives.
You should store it in the database instead of text file. There are many reasons for it. Go through this question for more descriptive answer. In short, you should choose database over files for security reason, speed, code maintainability and concurrency.
You can use LOAD DATA INFILE to read the contents of a file and store it in a table in the database in a structured format.
LOAD DATA INFILE 'data.txt' INTO TABLE db2.my_table;
You can also use largetext in mysql.But it would be slower and non-resilient.
Please check here
See there are some major things you should know before taking decision on where to save things
If the file is an image/Video/PDF
For this you should save the FILE NAME into the database and the image on server
If the file is a large text
For this you should save the file to the server as the database will not be able to take loads of text and many requests for long text at the same time and this will also save you space for more things in database
For any other thing, if you find it space consuming just save it on the server as this will give you space for database and more advantages
Well,I am learning the web development and currently working on PHP and mySQL,I am just totally a newbee to database concepts.To be honest Iam not sure when to create a table or when to create a database.I need some suggestions and help from you.
Okay I have these doubt kindly clear me this.I am not much aware of this but how much security does php file concepts provide us. Is there any harm in using file concepts of php?
Okay let me tell you these I want to save some data that user has entered into a text file on the server, the data might be like some message or something like his information,I wanted to save the data in a file and then save its directory path in the database. and while retrieving the data just get the file path from the database then retrieve it from the text file. Is this a good or bad idea of doing it? or should I need to save the user data in the database itself?
Similarly I also want to save the path of the images or pictures in the database and then just put the path in <img>tag.I got no one here to help me with this questions.So please help me with this,Any help is greatly appreciated.
Kindly let me know what is the way I should choose to do ?
For images and other file-bound resources, it makes sense to store the image on the file system and the path to it in the database. After all, file systems are great for storing files. You can store the file as a binary field in the database, so that's certainly an option. There are pros and cons either way. Personally, I prefer to keep the files on the file system.
I'm not sure where you're going with this:
the data might be like some message or something like his information,I wanted to save the data in a file and then save its directory path in the database
Is there a particular reason why this data needs to be in a file? Or are you just not sure how to store it in a database? If the data is structured and consistently organized then I can't imagine a reason not to keep it in a relational database. (And even if it isn't as structured, I'd probably still look into a database over the file system for this sort of thing.)
Images and other non-relational resources are generally file-bound, so keep them in files. But if you're just storing text in a text file for no other reason than that's what you've always done, I'd recommend using a database.
PHP provides only as much security as the underlying filesystem. But putting files on disk and saving the path in the db is the traditional method.
Files in a database are generally not the best solution. But that's mostly because people talk about storing binaries (e.g. images, zip files, etc...) which would be an opaque blob as far as the database is concerned.
With text files, especially small ones, it'd still be at least somewhat useable by the DB, even if only via SUBSTR() type matching/searching, so this is one case where storing in the DB could make sense.
There is a good rule-of-thumb here:
If it is something, the DB "understands" (such as text), store it in
the DB - you might later want fulltext indexing, search, text transformation, whatever.
If not (e.g. Images), store it in files
as all rules of thumb, this might or might not fit your index finger
When I do an import of data from a file, such as csv or text file, I would like to display on a summary page （table view) about what is going to be imported to the database, and user can select or deselect what will be imported into the database. I would like to find out what is the best way of temporary storing these data to be displayed onto the summary page?
To give a clearer understanding about what i am talking about, for example:
I have a csv file that holds a list of products.
I would do an importation to read the csv file and display onto a summary page with
table view and checkboxes to select/deselect some of the data.
After the selection, I would click the confirm button to store those checked data
So between the process of getting the csv data to the summary page for display, where should I store the data, in the database as a tbl_temp data and clean off when done, or just read directly from the csv file?
Thanks.
I would think an array would do the trick unless you think your environment is really unstable or, for user interface reasons, then just store to a temp file. Temp db table seems a bit much.
I would just display it in the browser, and stored? It's already stored, the uploaded CSV file!
Unless you don't run into an actual problem with that approach, why care?
Just use HTML to display the data read from the file in a web browser. Use standard HTML Form and form controls. Use PHP scripting logic to control what happens when the form is submitted. You could have the submit button hand off to a service or some other php file that could handle writing it to the db.
Why bother writing to a temp table, to just read back out and display in a form to be then written back to a perm. table.
If this were a process that you would be performing a lot, i might give it a little more consideration.