Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a POST register system. Simply every single post request that is sent to the site must be recorded as well as everything the user had posted ( in other words the $_POST array ).
I see 2 ways of doing this:
The right way - having a separate table registerPostInfo for post information where every single element of the array will be inserted as a new record.
The wrong way - creating an additional column to my registerPost table which would hold the json_encode()'d post array.
I'm asking for advice because eventhough it may be considered 'WRONG' I honestly think I'll be better off with the second solution, because this table gets flooded like crazy. I have made 2000 records all by myself in a one month testing period on a local server, if I were to proceed with the first solution, say there are an average of 5 elements in the post array, this means there were going to be 10000 records in the registerPostInfo table. Imagine that with thousands of people.. I'll be happy for any useful information about my issue and possibly a third way I haven't thought of.
Thanks in advance!
Depends on what the actual purpose of “recording” all the posted data is. If you just want this as a kind of log so that you can reconstruct later on what a user was posting should it turn out to be malicious or unwanted, then I’d say storing it as JSON or serialized into a single column is totally OK; whereas if you want to process that data in general at some point, maybe even search in it for certain parameter names/values, then you might be better off with storing it as single parameter_name|value records, all tied together by an id for each single POST request made.
So if the main purpose is not actually working with that data constantly, but only to “analyze” it when necessary, I’d go with serialized data. Easy enough to select it from the database by time of posting or by user id – and then the de-serializing part could be done by a script. And your secondary use, showing to the user what kind of content they have created – well that you should be able to get from the tables that actually hold that content.
Related
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 2 years ago.
Improve this question
We covered all these POST and GET requests topics in college but those three are still in my mind.
I was wondering since I'm not quite sure why I shouldn't be using GET request for those three examples. I'm just hoping that someone is better at this for explaining a bit more for all these options.
1.
sql = 'SELECT * FROM contacts WHERE id ?' .$_GET['id'];
Is it because if there isn't id then I wouldn't be able to get it and PHP shows me an error message.
2.
eval($_GET['user_provided_code'];
Is it because a person who enters his/her code can basically insert whatever he/she wants and can take over my computer or delete something.
3.
function toFarenheit($temp){
return ($temp * 9 /5 + 32) * $_GET['const'];
}
Basic thinking as for the second option, that we can't insert data with GET request and in this case person is able to insert whatever he/she likes.
Security-wise, there's not really any difference between GET and POST. Generally, GET is used for idempotent operations (like selecting rows from a database and displaying them) and POST is used when the request creates a change (like updating a row.) The problem in these examples is not that they use GET, it's that they don't validate untrusted user input.
There's nothing inherently wrong with building a SQL query from a value obtained from a GET request. The problem with this particular example (syntax errors aside) is only that it presumes the variable exists and contains a valid value.
eval() is virtually never needed and almost always introduces security issues. In this example, you're blindly just executing whatever the user gives you, which is a terrible idea.
$_GET['const'] might not exist. If it does exist, it might not contain a number. There's no real security issue, worst case is it'll evaluate to zero and return a bad result.
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
Actually i want to save Base Abilities for game. i have two option one is to save a very long string like this [{'baseId':1, 'baseName': 'xyz'},{'//', '//', 'etc'}] or the second option is to save these type of record in multiple rows and column. Or if someone has a better option to do this you can suggest me and thanks in advance. :)
This is a common problem. The normal answer is: "Use the relational database as it should be used, with well defined columns and rows." That is, your second option.
Storing a complex JSON (or other type) object in a field can be a reasonable thing to do. However, you need to be sure of the following:
The field is only being retrieved to pass back to the calling application.
The field will never be used for filtering results.
Components of the field will never be needed.
(I can add that for JSON specifically, the third can be relaxed in the most recent version of MySQL because of JSON support.)
In other words, the field is a "black-box" or "blob" that has no meaning to the database.
Your values would seem to be relevant for storage in a database. My reaction is that you should parse the values and store them in a more correct relational format.
This is a typical object oriented to relational mapping problem.
In short it depends on the ease of READs and ease of WRITES.
If you think that this data is always going to be retrieved as a whole JSON and being written a whole you may want to use MySQL JSON Data Type or even a varchar like type.
Otherwise map the fields to a new table and and store as rows. Here you may be better off with one row representing 1 object instead of complicating futher and spanning the field to rows. Again look as your READ and WRITE use cases with respect to partial or full entity.
Then there is a programming model to consider - which model keeps your code simple and less prone to bug.
The other aspect is the effeciency of storage as well. How many records are going to exist ? The data type affect this e.g. blob types TINYTEXT and LONGTEXT
are different when it comes to storage.
All these askects need to be considered.
There is a 3rd option You store the items in multiple tables.
Firstly your main table for the very basic details that everyone will have. In this case probably the name, and a few other bits.
A second table contains a list of all the abilities that each character may or may not have.
The 3rd table has multiple rows for each character, one for each ability that the particular character has.
This way details may be checked directly using SQL, but if extra abilities are added for certain characters in the future there is no need for any table changes, merely just adding a bit of extra data.
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 was wondering what was the best way to generate a followers list using PHP and MySQL database. So here are the two ways I have found that this can work.
Here is the first way that I have found: I can create one column for each user that will contain all of the ids of the users that they follow. When I go to retrieve the list, I explode the list of ids so that I can select all of the data from each user.
Here is what it looks like in the database:
User ID Following
1 2,3,5,6,7,9,10
5 10,5,2,20,1
The other solution that I have found is that every time a user wants to add someone to their "following" list, the database will contain 1 row just for that specific person that they are following.
User ID Following
1 2
1 5
2 1
1 42
Therefore, in the long run, I am wondering which would be the most effective way to organizing the data and retrieving data to display for the newsfeed - the easiest and least cost effective. (I already have a table that contains all of the users posts).
Use the second option: a table with a row for each following record. Databases are designed to handle millions of rows so don't be scared of using them. In particular, rows storing just integers will be very efficient. You can freely use joins and other features.
The comma separated string solution will not scale up because it's very inefficient for the database engine to have to parse that out constantly, especially if it grows considerably. Also consider what field length you'd put on that, you might find you have to regularly resize it as users gain more followers.
The two solutions are of two types for retrieval and manipulation of the data. This will be a call for taste and strengths.
DATABASE/JSON/CODE
The first will be a code solution to manipulate the data after retrieval of the string of followers. The cons to this are the typical storage of information as a delimited string is the bane of database admins and programmers. If you to add meta info to the follow connection you can't. Adding e.g. "followed since", "tag", "followers in group" becomes impossible without doing some very nasty hacks that will add unwanted code to your app.
You can fix this by storing the followers as a json object or array. This will make your code better and ease the manipulation. It will allow for adding meta data to the follow. Once you've done that the pro is polymorphism of a function to do things is easier after a single database call SQL in every instance. But the code can become complex after a bit, an d scalability might be a problem. Think about user that have thousands of followers.
DATABASE/JOIN TABLE/ MVC MODEL
The second is a SQL solution is called a join table this has minimal cons like making a database call for each manipulation slows things down. You can fix things a bit if you are using MVC. I recommend making a model for polymorphism.
The pro is you can add other information to this table like the date the follow started or ended. This makes your app more comprehensive. The SQL becomes more complex but the coding is easier.
So all things adjusted and equal(after changing to JSON) you only have to choose between being a coder or SQL'er. Don't let a thing like scalability or performance influence your decision until they are actualities. But storing CSV in the database is a thing you should NOT do.
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 8 years ago.
Improve this question
I just have a general question. I am concerned with the speed of my PHP website, which is set to go into production soon.
My concern is the length of time it takes for the page to run a query.
On my page, I have about 14 filters in an HTML form. I am using the method GET to retrieve all the values from the filters. Granted, not all 14 filters have to be used. A user can just search off one filter. Of course, the more filters are selected, the larger the query becomes. But the larger the query becomes, the quicker the page loads. So it's beneficial for the user to select more filters over using just one filter.
All of the filter values are then sent to an INCLUDED PHP file, which then builds a query based off of the user's filtered selection.
The query runs and I am able to print the selected data into an HTML table on the original page. The problem is the it can take quite some time for the page to render and finally display the data-table.
The database is not too large. Maybe between 20K - 40K records, though there are over 20 columns per record.
When I run the same query in MySQL, it returns the data faster than it does on the page.
Here is where I believe the problem might lie.
Within the form are the filters. About 5-6 of the filters are running queries themselves to populate the selection data for the user.
I believe that after the user runs a query, the page refreshes and it has to re-run all the filter queries within the form.
If this is the case, what steps can I take to fix this issue? If any. Should I place all of the filters in a separate file and INCLUDE them within the form? If not, then please advise what I can do to speed up the page loading process.
I have visited various websites in an attempt to fix this issue. Like this one:
http://code.tutsplus.com/tutorials/top-20-mysql-best-practices--net-7855
I am following just about every step suggested by that site, but I am still experiencing the page load delay.
I hope I can receive some positive insight.
Thank you in advance.
What you can do is if all the filters are static and do not disappear or change view when selected / changed value you can set the filters outside of the reload view.
Currently I am building a site that is dealing with AJAX query reload and have to deal with a very similar aspect. My fields are set outside of the reload and I have very fast load times.
If they are dynamic or need to change based on options chosen then I would set them as a separate reload. Basically determining which ones changed vs what needs to be displayed.
Hopefully this helps and explains well enough.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have an SQL table. With an SQL request with PHP I want store the result of this request in a variable. The probleme is that this request have a lot of valors.
In other worlds I want to store in my variable a lot of IDs Maybe with an array but i dont now how. And i want to use variable for another SQL request using PHP.
What I want to do: With the IDs that I store in this variable, show all the names that have the same ID BUT this IDs of names are in another table. I want to use the IDs of the first table to second tables, and show all the names that correspond to the ID on mi web site. All the names (IDs) not just one.
I dont have the code yet.
I hope is an easy question, and you may help me thank you very much.
Not entrirly sure what you are asking here, but for the first part, storing everything in a variable is very simple, but if you write the script well, you dont have to use a new variable.
$newVar = $_POST;
BUT, you don't really need to do this, everything is already in POST, just access it with a key: $_POST[name_of_what_you_want]
I think what you are asking is the basics of the CRUD website / database method. Create, read, update, and delete.
You will get your info from the client in your script, ie GET or POST.
Validate and scrub this data, prepping it for insertion into the database.
Insert this data into your database. In your case you are talking about a relational database. Basically, you have a table which stores the bulk of the data, each of those entries, or rows as they are known, which has a unique ID. Then you have other tables that rely on that unique ID to link that particular row of data to something else, be it a page or a category, etc., of your website.
Now that the data is in the database, you can query it and pull out what you need, based on a set of criteria, that you make up as you need. Then you build your webpage and send it to the user.
Without providing specifics of your project, I am afraid I cannot help you much further, but I hope this helps.
EDIT - based on your comment.
Here is a pseudo mockup of what you are asking for.
$sql = "SELECT name FROM table WHERE id='id_number'";
$data = mysql_query($sql); <-- assuming you are using MySQL
while($row = mysql_fetch_assoc($data)){
echo $row['name'];
}
What's going on? Query the database to pull out the rows with the ID you are looking for. Store them in an array, and step through that array, echoing the name to the user.