The IP Address problem is one that I am facing.
When stored as a string it is a VARCHAR(15), it is human readable but difficult to do range searches.
When stored as a BIGINT you can convert 192.168.10.1 to 192168010001. Still readable (just), you can do a range search on it and it now takes 8 bytes. For the pedants amongst you, yes I know you have to consider whether the column is NULLable.
When stored as an INT by combining the octets you loose readability, but storage is now 4 bytes and you can do range searches.
Consider that the IP address is coming from the log files of a large web farm registering millions of hits per hour and the 4 byte solution starts to look very attractive.
When it comes to deciphering the IP address when it is encoded within an INT you don't. Well, not straight away.
You do your data mining first and the significant IP addresses get decoded.
If you want to do searches for a range of IP addresses you use the udf that encodes the IP address in the first place to tell you what encoded values to search for.
I wouldn't recommend storing an IP address as 4 separate TINYINT fields for the reasons Joe stated. An octet by itself has no meaning, it is scalar but not atomic.