Splitting the password is bad.
Designing your own password hashing mechanism is not good, either. It is fine for learning purposes, but for production, this is a no-go, because you cannot know whether you did things right or not. It is a generic and all-encompassing flaw of homemade cryptography. Of all cryptography, really; but, at least, with public standards like bcrypt, you benefit from the review of many eyes during many years.
You say that the attackers "will not know the kind of hash you used". That's wrong; they already know it, probably better than you. First of all, they have Internet access, so they can read this very question that you ask on StackExchange. Also, the hashing method exists as source code somewhere, and some executable script or binary on your server, so it cannot be really secret. In particular, you want to hash the passwords before storing them because you envision an attacker who could obtain an illegal read-only access to the data stored by the server (otherwise you would not need to hash them); it is very conceivable that such an attacker will also get read-only access to the server code itself, and thus gains knowledge of the hashing method you use.
Last but not least, you cannot know how much your hash algorithm is secret. Much of security is about quantifying and measuring. With a password, you can estimate the entropy, depending on the generation mechanism; same for any secret key: keys live in a space of a size which can be assessed through mathematics. But the secrecy of an algorithm, which exists in various places, including source code, executables, possibly printed sheets, backups, and the brain of some developers ? How much secret can that be ?
Kerckhoff explained it quite clearly more than one century ago: you shall not consider your system as secret. Keys (and passwords, which are just a kind of key) are designed to concentrate the secrecy, while the rest of the algorithm must be considered as public -- because, most of the time, it is public knowledge.