I'll try to answer each question below:
1- I understand that we have to think of Contracts as "classes"
similar traditional web development. Does that mean that for our
example project we would create multiple contracts to complete the
final project and link them together? For example a user contract,
blog post contract etc.
You can think of contracts as classes, yes, but you don't structure the app the same way you would in JS or other languages. For example:
In other languages you would create a BlogPost class (with say - to make it simple - a title, text and publishedOn variables). Then, you would create an array of BlogPosts and fill it with the results of a query. In solidity, the way to go would be to create a BlogPosts contract that holds the array with said blogposts (which could be a struct that you define in the same file). Every blogpost item would live inside this contract.
2- If we do have multiple contracts I assume that they are connected
together via their address?
Yes, but you can also have contractA hold a reference to contractB in a state variable. For example, in a token crowdsale app:
In CrowdsaleContract:
token = createToken();
function createToken() internal returns (Coin) {
return new Coin();
}
Here, we would be assigning token to the result of createToken() function, which instantiates a contract Coin (the Coin constructor sets its name, symbol, etc). Later on, we could do token.someFunction() to call a function on the referenced token, and at no point we needed to know Coin's address at all.
3- If all users call the blog post contract at address xxxxxxx in
terms of the blog posts that each user makes are they stored
against/inside the address of the contract that is called and if so is
there a limit to the number of posts/data stored at the address?
As I said in 1) if you generated a contract for each blog post it would be extremely hard to maintain and extremely expensive to post. The way to go, oversimplifying it, is to have a BlogPosts contract that holds an array of blogpost struct. This blogpost struct would also have an author field which could be the address of the person who created it so you can later fetch the data of said author.
4- Looking at this in a traditional database sense i.e MYSQL how is
data then searched for within the contract? For example lets say I
want to search by all posts from user x or posts that contain a
certain string?
This would be extremely difficult if not impossible for 2 million records.
First, there's no easy way to query the data as you would in a Relational DB. You would have to retrieve the complete array and then filter it client-side.
Second, even then, if you had 2 million blog posts, manipulating such array in Solidity would be impossible. You will run out of gas before you can iterate or do anything with this array.
5- If i want to read data within the contract i.e the total number of
users or retrieve the total number of posts do this cost gas? I have
read that reading doesn't but some people say that it does if it is
calling a function within a contract.
If you are just reading data, it won't cost you gas BUT, gas is still used. You just don't pay for it. This means that you are still limited in terms of what you can do with the data. You wouldn't be able to, say, iterate through 2 mil records and count them.
You have to ask yourself if it's really worth it having all this data on-chain. Do you really need to store all the blog post data, users, etc, on-chain?
You could do something hybrid where you store the blog post data off-chain (mysql, mongodb, etc) so you can query it, filter it, etc. and then part of this data, is stored on the blockchain.
