Is that a good way?
In short, you're giving a hacker an opportunity to gain access to all your users' passwords, plain text. This has several consequences:
Given that users may be reusing the same passwords on other sites, this means that users' accounts on other sites could be compromised because of you. You might say that they had to use different passwords; I'll reply that you are the IT professional, not your users, and it's up to you to be professional and care about the confidential information your users trust you with.
This puts you at risk of being attacked. A hacker who knows that you store every password plain text would be inclined to attack your application or infrastructure, instead of an application which doesn't store any password.
In some countries, you may be liable for storing confidential information in plain text.
So what would be a better way?
Ideally, you won't store passwords at all. Instead, you'll use a service of a third-party which will handle account management for you. Those third-parties could be Google, Facebook, and a lot of other companies. Technically, this means that you'll be using OpenID (mentioned by Dan Pichelman in his comment) or OAuth (OAuth is technically not an authentication system, but is used as if it were, so it needs to be mentioned here).
Looking at the documentation of OpenID/OAuth, it could look scary and extremely complicated to set up for a beginner. Don't get discouraged by that:
Most languages/frameworks have libraries which do all the technical stuff for you. You just have to configure them, and it works pretty well.
OpenID and OpenAuth are used now for a long time and are extensively documented, with excellent support. The problems you'll encounter, someone else encountered them already in the past, and asked questions on StackOverflow and got answers.
It would be much more difficult to create your own system from scratch anyway, even if it looks easy.
If, for some reason, you decide not to use a third-party for that (although I would advise you to reconsider your choice!) then at least:
Don't reinvent the wheel; either use what comes with your language/framework, or at least use existent algorithms such as PBKDF2. Make sure you understand which algorithms are flawed, and which ones are not.
Don't work alone, but make sure you work with a person who has enough understanding and enough experience in authentication systems. Algorithms are one thing, but the way you'll handle session expiration, password reset procedure and hundreds of small details will make a difference between a system which would handle a part of the attacks and a system which would give unlimited access to any decent hacker in a matter of minutes.
when the user logs in I would have to load all registered users to the app and search for string equals to all the registered users and the user currently trying to log in.
No, you don't. When the user logs in, you search for a single database row which corresponds to that particular user.