Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm programming a LAMP stack online application that uses a very complex search form, I want to give the user the ability to name and save their current search for faster use in the future (they will be checking these results daily). What is the best methodology to do this? I've been coming across stored procedures, but this doesn't seem like what I'm looking for.
My current idea:
Pull php generated query into dedicated database for saving queries (all form input data is sanitized / validated). Is this a security risk? I know all form generated SQL is a risk of course. When the user wants to query with it, the PHP code will simply use the saved query over the form generated one. If I change the form generated query code in the future, this should prevent conflicts, but of course, it won't take advantage of any new design features.
I don't imagine this is "best practice" (or that there is one, in this case). Personally I think I'd rather store their search terms in a format devoid of context (say in a JSON-encoded object if there are multiple search terms or conditions), and then when they recall the search rebuild the queries from the JSON object.
(Storing the actual query seems to run the risk of old queries becoming obsolete if/when the underlying database structure changes. Storing only what they're searching for and rebuilding it allows you to accommodate for that.)
My $0.02.
To answer your question, yes. Regardless of how you store it, you would store the values they entered in whatever your form collects, then when they rerun the stored "search" you would go through that structure and remake your query.
The table might have search_id, user_id, search_name, parameters and whatever else. They pull up a list of their saved searches, choose one, execute it, you pull parameters, rebuild the query, run it, and display the results, just as you would when they did the original search through the normal form.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am building a social networking website and should i use JSON instead of database for storing users posts and comments? Is it good and secure?
JSON is a format, not a file standard. So you could even think of storing JSON in DB.
So, you will need to answer two questions
is file format better than real DB format (like MySQL like databases)?
is JSON format good for the use I have?
File format
Because you will have to deal with quick access and sometimes complex queries (search engine, statistics, ... ), it's clear that a DB system will be much more efficient than a file system oriented solution. File creations / openings / writings / closings need a lot of time and it will be a pain to create search queries. In PHP you would have to open all your files and put them in memory beforte doing the real job.
Using a Database, you would perhaps be directly be able to ask the system if someone with "%john%" in his name has posted something about "%futurama%" in the title.
So... one point for DB
JSON format stored in DB
One more time, you'd better use rows capacities of the DB system. By that, I mean using a author_id row for example. It would greatly impact the perfs. On the other hand, you would have to think of complex queries dealing with the downsides of the JSON format in your DB engine query.
One more point for not using JSON
But when using JSON?
JSON is great when dealing with APIs. If you need to serve data for an application (i.e. an Angular2 front end that will query your API), JSON is a native format to manage data... but not for storing it... JSON is more often used for stream purposes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
The Problem
I have an app that scrapes data and presents it to the user, directly, because of lack of disk space.
This data is very volatile, it can change within minutes. Much like the stock market.
Since the data changes so often, and it varies from user to user, it is useless to save it in a database.
The question
I need to sort the data presented to the user, compare it, link it etc. A lot of functions that a database provides. Yet I cannot save it in said database because of the above conondrums, what should I do?
What I've Thought of Doing So Far
I've tried organizing the data presented to each user using just PHP but seems troublesome, fragile and inefficient.
Should I just create some sort of virtual table system in MySQL just for data handling? Maybe use a good database engine for that purpose?
Maybe I can save all data for each user but have a cron job remove the old data in the database in a constant fashion? Seems troublesome.
The Answer
I'd like some implementation ideas from folks who have encountered a similar problem. I do not care for "try all of the above and see what is faster" type of answers.
Thanks all for your help.
If the data is of the type you would store in a db and you would benefit from being able to query it in ways that are more difficult in PHP, but you just don't want to keep it, you can still use a database. You can create temporary tables, insert raw data, and query it to get what you want. When you close the db connection, the tables disappear. Even though the script names them the same, the database will actually create a unique set per connection so each user will have unique data. This solution may not perform as well as you need so do some testing to see if it's suitable for your situation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have to pass parameters throught my pages. For exemple ids of my database.
Is it a good idea to do so: www.example.com?id=10
Or have I to hash the parameter:
www.example.com?id=b1d5781111d84f7b3fe45a0852e59758cd7a87e5
It is really important to hash this one?
Thanks
Best regards
There is no need to hash Id's in query string. Yes it is visible to everyone but it's a common use. you should verify in your server side that this parameter cannot harm your application
How are you able to trace back the id for that specific hash? You will create a bottleneck if you need to get all your database id's and hash those to find your matching record.
Using id's in urls are commonly used, just dont put any sensitive data in your urls to protect your visitors (and yourself).
Also note that every visitor is evil. Always validate incomming data and do some proper error handling incase someone is messing around with the urls.
Ids are ok but I think the spirit of this question may be the result of a very real concern.
As others have said, you should expect evildoers to be using your site. Of particular concern with poorly design web applications, are SQL injection attacks. The ids themselves aren't an issue but if your backend is building a string of SQL, you could have issue. For example if your PHP code is taking that parameter and creating this SQL:
SQL = 'select * from product where id ='.$_GET['id']
Executing this SQL would be a major issue if someone changed their browser to call this page:
/product.php?id=1;DELETE FROM USERS;--
...you could end up with an empty database table.
Every language has its own way of protecting from this kind of thing, so make sure you are doing it the right way. For example, see this SO question How can I prevent SQL injection in PHP?
See https://www.owasp.org/index.php/SQL_Injection for more info
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I think of creating an administrative panel where all the inputs/textareas/selects that run the 'site' are created by MySQL.
What's better, create a row for each input/textarea/select referring to a page, or put the information of all inputs/textareas/selects each page in a single field and use the php explode in order to use the data ?
I advise to use case 1. If you will need to change PHP to some another technology (i.e. Java or Python), then it may have no "unserialize" function.
Also, it is easier to read data if you will need to analyse it manually.
Case 1 -- you're going to be storing that information in a relational database, so you may as well get the advantages that offers (for querying, udpating etc.) It will allow you to more easily manage your fields and change attributes of those fields.
I'm inclined to say Case 1 is better - keeps data better organized. Also, SQL is FAST, much faster than PHP, anyway, so if there is one less task for PHP to do (i.e. explode), the better.
Finally - it will be so much easier to maintain case 1. If you wanted to update the name of a field of a certain form, for example, you can...do just that, update only the name of that field. Otherwise you'll have to potentially do a find and replace, which may mean having to select, read, find, replace, update, a much more cumbersome operation.
Just my opinion, but I would go with case 1.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am new to making games, and I am writing one for fun using php and javascript. I am using MySQL to store all of the info of the users of the game. The game is kind of like managing a sports team. You have a few variables (cash, assets, players, staff, etc...) and you take on all the roles of a sports manager. I know it exists, this is just a personal challenge.
My question is, what is the best and most efficient way to get information from the database into the game?
1. Do I have to run an sql query on every page?
2. Do I have to update my database EVERY single time something is updated?
3. Is it possible to get all of the information from the database when the user logs in, let him/her play, then only update the database with the new information when the session is killed?
Sorry for the lack of code, just looking for a starting point because it would be helpful to me to know this before I start writing a lot of the game.
Thanks
No, you don't necessarily have to run a MySQL query on every page load. You could store the results of such queries in a cache system such as memcached, or keep necessary data in $_SESSION.
No, you can use similar workarounds as before, but if the user disconnects you may end up with unsaved changes.
Well, you could load the data relevant to the user and write your own session handler for saving the data when the session is destroyed, but although I haven't ever tried it I would say there's a very real risk of losing data if, for example, your server is restarted or PHP's garbage collector callback is not called for some reason.
Overall, I think you may perceive SQL queries as much heavier than they actually are. If your database structure and indexes are set up correctly, your queries and updates shouldn't take longer than about 0.01 seconds each to complete.