Simple Entity tutorial?

Moving Beyond Nodes
What Where and When Entities
Programming Hello Drupal Entitiy

These helped me tremendously, maybe they will help. Good luck. Also I don't know where I copied this from but it works too.

The "everything is a node" meme, takes shape in Drupal 7 as "everything is an entity" and a type of entity is a node. However, also users, taxonomy terms and comments are entities and entities can immediately plug-in to the Field API and have fields added to them.

If you want to introduce some new fancy way of dealing with things and take full advantage of the power of Drupal you don't need to write a module that turns X into a node, rather you create your own entity (take a look at the Awesome Relationships [This allows you to create relationships between any two entity. Sharing the field between two entities will show the relationship on both entities so this is unidirectional.] module for a great example).

This also means that one can now at least imagine a Drupal without nodes because the architectural tools to allow you to that are there. Nodes are just one type of entity. Of course, while you can imagine it actually getting that done at the code level is still not that simple since quite a few things are hardwired. But the first vital step has been taken.

Entities are the things, the data, the information, the "stuff", that we want to deal with in our Drupal application.

Entities have a common programmatic interface through which (most) of their behaviour is defined.

So the first thing Drupal entities are is means to streamline how we deal with the basic Drupal "stuff" of nodes, comments, terms and users.

Now comes the really interesting part to people that don't worry so much about how the core of Drupal does things.

1. You can define your own entities that plug into the whole Drupal way of doing stuff.

2. Any entity can have fields attached to it.

You can now actually create data structures specific to your application domain with their own database table (or any other storage mechanism really) plus a standardised way to add fields to them. No need to turn nodes into something they are not.

A few examples:

The Drupal 7 Commerce solution uses Entities to describe a line item in an invoice. As ChX explained to me in IRC they found this a convenient way to group all the fields related to a line item without having to re-purpose nodes for the job but also without having to introduce a completely custom way to deal with data.
The team over at Examiner.com use entities to store user profile revisioning information (functionality they are hoping to release soon).
The Drupal 7 Rules module uses entities to store Rules configurations.
So Drupal entities are:

A way to describe to the rest of your Drupal application something that is relevant and unique to your domain, that can have its own database table, but at the same time...
...use Drupal APIs to add fields to it and interact with it in a variety of ways, which means...
...that you get lots of stuff for free such as Views integration or the ability to use MongoDB for storage.
But how do you make the choice of when to create a new entity, whether you just attach fields to it or keep all the data in its own table, or simply do it the old way and re-purpose nodes?

Essentially, if you are faced with having to put information into a custom table consider whether defining an entity and attaching fields to it through the Drupal APIs might be worthwhile. And let me give you a hint - the answer is: yes, it probably makes more sense to use entities. There is practically no drawback to exposing a custom table as an entity.

While in Drupal 6 re-purposing nodes to do your bidding is very useful, there is something inherently inelegant about it because after all nodes are really designed to do one very specific thing - store articles. In Drupal 7, however, you can create your own lean entity and attach to it just the fields you need. You don't need to carry along node functionality (e.g. author, publish date, etc) that you don't really need.

According to both ChX and DamZ the base table representing your entity in the database should generally be kept simple and you can attach fields to entities to define your data structure.

The only reasons to consider adding data attributes directly to the entity and not through the Drupal Field API is if the data is quite specific and is not well served by any available field type or if performance-wise it makes more sense to query only the base table (for example if you plan to frequently query it) to get information out rather than having to query both the base table and the table where the field information is saved.

Keep in mind, however, that a major driving force behind the architecture of entities and fields is scalability - so if you are really concerned about performance you probably still want to use fields where you can decide exactly how they are stored (e.g. in a MongoDB database rather than MySQL).