The bottom line:
You need to make a website where there will be a list of users with passwords, as well as the date of completion of payment for services. And you also need to make a payment history.

Question:
Can I improve my table structure for this task?

I see it like this:

  • Creates a clients table
 ------------------------------------------------------------- | id | name | pass date | price | ------------------------------------------------------------- | | | (дата окончания услуги) | (цена, которая | | | | | будет подставляться | | | | | в историю оплаты) | -------------------------------------------------------------
  • Creates a history table, in the cells of which are written ID users
 ------------------------------------------------------------------------------ | id | jan | feb | mar | apr | may | jun | jul | aug | sep | oct | nov | dec | ------------------------------------------------------------------------------

As a result, the withdrawal of the payment history should look like this:

 Юзерник | 15 январь 2015 | 50 рублей Юзерник | 13 февраль 2015 | 50 рублей Юзерник | 19 март 2015 | 50 рублей

etc.

Closed due to the fact that the question is too general for the participants PashaPash ♦ , fori1ton , Nofate ♦ 21 Apr '15 at 18:07 .

Please correct the question so that it describes the specific problem with sufficient detail to determine the appropriate answer. Do not ask a few questions at once. See “How to ask a good question?” For clarification. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • Why jan feb mar apr dec jun jun aug sep oct no dec? Replace them with time_payed - Isis

1 answer 1

You form a list of requirements for the site / project, how it should work, then go over the plan of your program. The first thing that immediately arises from the requirements is secrecy and that the payment history is not lost. Those. As a direct text, passwords cannot be stored, save only the hashes that will be checked and the idea of ​​separate column months is very strange - and years? Why not just keep the payment date? The idea of ​​the question is understandable, but it is not correctly formulated. You can do everything in different ways, you get paid money (or you are going to earn money from the project) for taking responsibility and choosing a solution, and not shifting this responsibility to stackoverflow.
https://www.gnu.org/philosophy/free-sw.html
"Open source is like free expression, not free beer."

  • I do not shift the responsibility, I asked how to do better than what I described, and that’s all. If you don’t have the answer to this question, you don’t need to load it.
  • Collect the requirements for the project, take the current decision and go through the points - secrecy, performance, history, etc. specific to the project. passed / passed / passed ... - everything means ok. - hardsky
  • You are wrong, I asked a specific question --- I indicated my table structure and asked for the best option or correct - fosa
  • 3
    Your "specific question" is not clear to everyone, maybe. For example, for me (and, I think, for many), it is obvious that in the current formulation of the task, the history table should look something like this: id, user_id, payment_date . If for some reason you are not satisfied with the obvious option, or if there are any additional conditions, etc., then nothing is said about it, and regular telepaths are now on vacation. - user6550
  • but then it will be a lot of entries in the table - and with my options like less - fosa