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.
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 4 years ago.
Improve this question
I need to store one global decimal value.
Would the best way to approach this be to store the value in a .txt file, or make an entire table for it in MySQL which will contain a single row for the value, or is there a different way?
It deppends on how often you will access it and how performance critical your application is. In brief DataBase should be your default unless you have a strong reason not to.
The reasons to keep the data in the database it's because it makes everything simplier and neater, backups don't need to worry about random .txt files that may be overlooked (And this a incomplete backup). If you need to set up a cluster it's a real PITA to keep files real-time synched while most databases support it easily, etc.
Why wouldn't you keep something in the database?
It's a enviroment value and thus in each installation of your
software the value may be different while using the same DB (In this
case people use File storage like the usual config .yml)
It's really performance critical to
have a top notch access-time to this data, for this people use
specialized engines to store such data (Redis, memcached, etc)
Now, answering your question, how to store it in your own db, that's up to you, but I would think something like a table named "GlobalConfigurations" with a column key and value could be a good approach. So that if you find any other variable with the same behavior you can put it there.
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 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.
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 8 years ago.
Improve this question
I have a simple question! I want to create my website with multilingual content, but i have a doubt about which is the right way to do this.
Option 1: Create a .php file called for example lang.en.php (where there is an array of all the strings I use on the page) and include it in the header.php file, so that to add a new language i only have to create new files like lang.es.php
Option 2: Store the strings in a database table and take them with a query.
Now my question is this: when i will upload the website on a real server, which one is the faster method? which one slows down less?
There is also an option 3 use mo/po files which are specialized for the task and also kinda nicely handle singulars / plurals for you.
However being sanely able to edit those files you would need to provide a GUI. But that should also be the case when you are using the array in a php file approach.
It's pretty hard to tell which way is the way ™ so I think I might close your question as too subjective.
When you are going for the database approach I would personally have a way to export the texts to either a po file or a array in a php file to prevent having to query the database for those mostly static texts.
To answer you question po files might be faster, however with opcache it might be pretty close to eachother. If you really want to know it the best thing you can do is do some tests with either approach because I just simply pulled the speed of po vs static array in a file out of my arse :-)
P.S. when you are benchmarking both methods also please keep in mind that whichever method you are going to choose performance is most likely not going to be the bottleneck so choosing one or another for performance is probably a bullshit reason.
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 8 years ago.
Improve this question
I have a small question about performance during dev (web especially) :
Is it better to :
perform operations directly on the DB and retreive a "ready" result
OR
retreive the data from the DB and then do the operations?
Mat is right (see comments): there is no general answer to that. It depends on the structure of your data, on the queries you want to run and on your database system.
Nevertheless I would say, in most traditional cases it is better to join, filter, group, cumulate and sort your data directly in the DB - just because your DB is built to perform exactly this kind of tasks. If your data structure and indexes are built up right, it will be hard to write code beating the database in terms of performance on this actions.
Indeed, there are complex queries where it is better to split it up and do some work in your code. But unless you have more than 10 tables involved or big sub queries, you should not think about this to much.