How to design a dating site database on MySQL?

Question

MySQL

I am writing a dating site using MySQL DBMS. Here I think about such things:
1) in the questionnaire, the user selects one from 9 countries. Is it better to bring them into the table through enum or do normalization?
2) is it worth making the fields "first name", "surname", "date of birth" keys for using B-tree indexes? (I misunderstood this topic)
3) in Schwartz's book, etc. "optimizing mysql performance" read that it is better to avoid NULL values ​​and if there is no information, replace it with an empty string. How to do it? Just don't write anything in the "Default value" field and it will automatically be filled with an empty string?
4) and if you do normalization, is it better to use the Memory storage subsystem?
PS:

Answer 1

1. ENUM is generally quite a big thing with 65535 options. But still I recommend doing it through normalization, this dictionary may still be useful to you somewhere.
2. Keys should do what you will be looking for. If the data at the end differs little, and the main changes at the beginning - it makes sense to limit the index in size (ATTENTION ONLY TO SAVING MEMORY). For example:
abcd
bacd
dxdc
aabd
The difference between the given strings on the last character is not significant, therefore the index can be limited to 3.
3. Here the grandmother wondered for two, if you have an index for uniqueness (NOT primary), then you can get a NULL set, but not a "" set. NOT NULL I recommend to use if you require data to be filled in mandatory.
4. Of course MEMORY! Just one failure in the DC and you will have work for another half a year, that's great)) You can store in memory only what you agree to lose at any time.
If for good - memory tables firstly have a lot of limitations, secondly - they lose to kv storages like memcached / redis in terms of speed, and thirdly they do not support preemptions.
For what period?
If a day is... not a high visit, you can even afford foreign keys.
If in a minute (and really a lot of data) - this is already interesting, forget about FK, the recalculation of indices will be too expensive. Under the search - look towards the elasticsearch cluster, you will also most likely need a memcache cluster. It will be possible to pull a DB but on a minimum. The main work will have to happen in the background, so pick up a queue server like rabbitmq, or something like that.

Answer 2

1) Non-scalable solution! All countries must be placed in a separate table.
2) Depends on final requests. Make at first without indexes, then analyze requests. Without a full architectural view, it is impossible to say which indexes will be required))
3) Right! If you do not know for what purpose this field should be NULL, then make the field type NOT NULL.
How do you create a database?
4) I did not understand the question

Answer 3

1. directory of countries. store the country ID in the questionnaire. connection "many to 1"
2. xs what are indexes.
3. it is better to use null. Perhaps they misunderstood the topic or there was some nuance.
4. innodb