content type or normal er table, that is the question I was wondering, when should a drupal developer use normal er table instead a new content type? Is it never? When expected node entries reaches 100 000? i googled it and i didn't find any good answer. 

selecting from custom content type with number of fields is very time consuming, because all the join-s. If you have 5-10 content types, each with 10 fields, and expect a lot of nodes, is then the right time to forget about content type?

What are your experiences in this matter?
If you are using Drupal 7, instead of using plain custom tables, use a custom entity type, this is really easy to do with Entity API This gives you basic integration with Views and some other modules such as Rules 'out of the box', and customisation is very easy to handle.

I do not see entities having much overhead above a plain database table when the entities are not fieldable. I have worked on a site with millions of rows of data, which is all available as entities, and we load several thousand of them at a time when necessary, this does require a memory limit larger than 128MB, but I haven't seen memory usage go over 256MB while paginating a thousand or so entities at a time out of the possible millions. (Bear in mind though the entities are not fieldable, and we are using APC which does reduce memory usage.)

You can then also use the full power of entity_metadata_wrapper(), which is really awesome, and simplifies code.

Basicly, entities give you the benefits of a content type, without the overhead of revisions or comments. In fact, nodes are entities, so are taxonomy vocabularies and taxonomy terms.

It is definitely a best practice to use entity API to access entities as this allows all the proper hooks to be run, such as clearing the necessary data from entity cache. However, you are not forced to always use the Entity API to access the database entity rows, but do be aware that there are extra risks and gotcha's attached to this.