Here is the deal, yes, if you encrypt with ECB and use a new key for every block, you don't fall prey to the common ECB mode weaknesses, but that also means you have to store all those keys. That doubles your storage requirement. I can't think of any good reason to do this. Why would you increase your storage requirements so much just to avoid having to use an IV? This seems entirely inconsistent with your statement that "Due to a space problem, I'm planning to use no salt and no IV." Using a new random key for every block only makes the space problem worse (though maybe in a different place).
One of the most common modes of operation is CBC mode. With this mode, you only have one key and one IV. The blocks are then chained together, mitigating the typical weaknesses of ECB mode. Thus, for the additional storage overhead of one single block, you can get the same security as your ECB+random key for every block idea. This is a significant win for storage and is also a win for efficiency as you can compute the key schedule once (with AES).
Now, that said, these days, it is important to consider adding integrity protection to your ciphertext. Both your method and using CBC suffer from a common flaw, you cannot detect (in a cryptographically secure manner) whether or not an attacker has modified the ciphertext. To gain this protection, we use authenticated encryption.