PHP for undemanding. Database on the knee.
Even if I have 1000 clients, there will be no urgent need for MySQL for me, but for now there are significantly fewer ... about 50, this is not a question at all.
Automation of the following task: it is necessary to store the Login and Time (registration) for each client.
There are 50, even 100.
Maybe then a couple of parameters will be added.
The easiest way is to store data in files, well, I don’t like SQL for such simple tasks. Therefore, the decision was called - On the knee.
File format?
At first I wanted to make for each user a separate PHP file, which you simply execute if necessary (like JSON)
It is very convenient, but it must somehow be generated - inconvenient.
In PHP, there is a functionality for working with the CSV format - I don't like it either. Once on Perl, I wrote my database using object serialization.
those. we take hash. Serialize it and write. What is there in the file is no longer important, It is desirable that you can fix it easily with your hands.
Well, that's all ... In PHP, there is the same garbage.
As a result, Prostetskaya DB writes like this (PHP4):
$ USER ['timepaid'] = $ dt + 2,592,000; // gene hash
$ userdata = serialize ($ USER); // serialize
$ handle = fopen ('mother-folder /'.$ u.'. txt ', “w”) or die (' Mozart ');
fwrite ($ handle, $ userdata); // write on the knee
fclose ($ handle);
')
And we read like this:
$ userdata = file_get_contents ('dam folder /'.$ u.'. txt '); // read the file
$ USER = unserialize ($ userdata); // unpacks
if ($ dt _ <$ USER ['timepaid']) {} // and work with the finished hash
Face Benefits:
1. Very quickly write it all
2. There is almost no code (for PHP5 everything will be even shorter)
3. does not require Baz purchased from hoster
4. Through FTP, you can easily correct any data
5. Problems with simultaneous access are practically excluded. for each user your file
Disadvantages:
Naturally, this is only for the initial stage, when clients will pass for 500-1000, they will have to switch to MySQL, because FTP will go muddy for manual editing.
Automation of the following task: it is necessary to store the Login and Time (registration) for each client.
There are 50, even 100.
Maybe then a couple of parameters will be added.
The easiest way is to store data in files, well, I don’t like SQL for such simple tasks. Therefore, the decision was called - On the knee.
File format?
At first I wanted to make for each user a separate PHP file, which you simply execute if necessary (like JSON)
It is very convenient, but it must somehow be generated - inconvenient.
In PHP, there is a functionality for working with the CSV format - I don't like it either. Once on Perl, I wrote my database using object serialization.
those. we take hash. Serialize it and write. What is there in the file is no longer important, It is desirable that you can fix it easily with your hands.
Well, that's all ... In PHP, there is the same garbage.
As a result, Prostetskaya DB writes like this (PHP4):
$ USER ['timepaid'] = $ dt + 2,592,000; // gene hash
$ userdata = serialize ($ USER); // serialize
$ handle = fopen ('mother-folder /'.$ u.'. txt ', “w”) or die (' Mozart ');
fwrite ($ handle, $ userdata); // write on the knee
fclose ($ handle);
')
And we read like this:
$ userdata = file_get_contents ('dam folder /'.$ u.'. txt '); // read the file
$ USER = unserialize ($ userdata); // unpacks
if ($ dt _ <$ USER ['timepaid']) {} // and work with the finished hash
Face Benefits:
1. Very quickly write it all
2. There is almost no code (for PHP5 everything will be even shorter)
3. does not require Baz purchased from hoster
4. Through FTP, you can easily correct any data
5. Problems with simultaneous access are practically excluded. for each user your file
Disadvantages:
Naturally, this is only for the initial stage, when clients will pass for 500-1000, they will have to switch to MySQL, because FTP will go muddy for manual editing.
Source: https://habr.com/ru/post/19880/
All Articles