Choosing between hash functions instead of providing a salt for a password hash I am working on some programs that require the users to store their passwords in my databases.

However, due to the fact that I am not sure whether salt should be stored in databases due to my approach:

(1. I am able to create a random string with the help of ASCII table)

(2. I am able to create a unique ID like a random string similar to the User's UUID under Google Firebase)

Here's my approach, the users are required to enter a "Security_String".

The allowed format only employs numbers from 1 to 5.

1 represents SHA-1

2 represents SHA-224

3 represents SHA-256

4 represents SHA-384

5 represents SHA-512

After I collect both Security_String and Password from the users, then Password undergoes a series of hashing loops based on the Security_String. 

In this case, will the generated hashed password be considered safe enough? Or is it better to generate a hash password with salt by using my approach?

Also, is it better if I add another spicy ingredient called pepper during the hashing process?
Generally you don't want to switch algorithms in cryptography. You'd have to deal with different workloads. Furthermore, the choice of algorithm would be just another salt, if a tiny one. However, your approach doesn't disallow the building of 5 separate rainbow tables. So the reason for a salt isn't met.

It is unclear why you would not be able to use a general Password Based Key Derivation Function (PBKDF) / password hash. So yes, using a well known good scheme with a a salt is indeed more secure.

A pepper can certainly be helpful; if the DB is stolen minus the pepper then it will be next to impossible for an adversary to start guessing passwords without the pepper. Of course the pepper should then not be kept in the DB, because that would negate the whole idea.