How to store the field "salary" in the database?

Question

Database

The salary can be different:
33,000 rubles
from 33,000 rubles
to 33,000 rubles
28,000–30,000 rubles
33,000 rubles + interest
33,000 rubles +
piecework bonus 70%
negotiable
, and so on and so forth
What, from your point of view, is the best way to organize the storage of this data in the database?
Ideas came to indicate the lower and upper limits (segment), as well as the type (piecework, equal, from, to, etc.). Or, for example, indicate only the minimum (from X rubles) and possible deviation, and consider an empty field as “negotiable”. There are a lot of options, but maybe there is something more or less universal?

Answer 1

You can try to go this way.
3 fields
MinSalary
MaxSalary
PercentSalary
1. Constant salary MaxSalary=MinSalary, PercentSalary=NULL
2. Salary "From" MinSalary=someValue, MaxSalary=NULL, PercentSalary=NULL
3. Salary "To" MinSalary=NULL, MaxSalary=someValue, PercentSalary=NULL
4. Piecework MinSalary=NULL, MaxSalary=NULL, PercentSalary=someValue
5. Salary itself + % MaxSalary=MinSalary, PercentSalary=someValue
6. Negotiated, you can leave all NULL, but I think it would be more correct to limit it to certain frames “From” and “ Before"

Answer 2

I don’t know what you are doing there, but I can assume that the database of vacancies. And the applicant will watch it.
Firstly, “piecework 70%” - how much will the applicant receive per month?
Secondly, it will be convenient if there is a filter that you can use. And in the filter, only one field is needed: “minimum salary From”. It is unlikely that anyone will limit themselves from above.
I think that you need to store two values ​​\u200b\u200b“from”, “to”. The absence of a value in a particular field means unlimited. Both values ​​are missing - the salary is negotiable. To specify a fixed salary, you must store the same value (how it will be entered is a separate conversation). Interest, bonuses, etc. can be ticked, stored as flags.

Answer 3

Get two separate tables for salaries and allowances.
Allowances are premiums or percentages. There structure is very simple.
Allowances and salaries must have a reference to the employee. (maybe one person can receive several salaries and different allowances)
In the table with salaries, store the minimum and maximum salaries, the type of currency (rubles, dollars),
the type of the salary itself (from, to, etc.)
In the code itself, I would make BasePrice and would inherit from him IntervalPrice and so on

Answer 4

I have not heard of a universal standard for storing wages in a relational database. I don't see any problem in creating a database that takes into account all the possibilities.
Or are empty fields scaring you? You can get rid of them, but performance problems may begin, then you will have to make a redundant table for selections, where all these empty fields will still be. In general, don't worry.
If you want to know what are the payroll standards in general, then:
www.google.com.ua/search?q=basic+forms+accrual+salary+payments

Answer 5

With relational databases, there are 2 options: 1 (in my opinion, the most preferable) is the creation of fields for all possible options, 2 is the storage of serialized data in a blob. Option 2 has a huge disadvantage - it will not work to sort.
If a NoSQL solution is allowed, then I would do something like this:

{
  /* ... */
  "salary": {
    "fixed": 30000,
    "bonus": 1, // Тип бонуса, например 1 - процент, 2 - премии и т.п.
  }
},
{
  /* ... */
  "salary": {
    "range": [28000, null], // Сверху не ограничено
  }
},
{
  /* ... */
  "salary": null, // Не указана (договорная)
},

Answer 6

It's decided. We make two fields: from X to Y.
X = X rubles
X–Y = X–Y rubles
Y = up to Y rubles
—— = negotiable (including piecework, project-based, shift, daily, flexible schedule, etc.)