The main problem I see with your second structure is that you have to parse out what each row of information is.

I would basically keep your original "place" table structure, but add a ParentID field to it. I have a separate table for states, which holds different information.

Start by creating a properly normalised data model and the design will fall out of it naturally.

you should start with the canonical definition(s) you will require for a "place".
if a place is a "point on a map", you probably want to define that as latitude and longitude with the supporting textual descriptions such as the address, or "highest point in florida", etc.
but "place" can also be defined as a line, a boundary or an area, such as "Route 66" or "the shore of lake erie" or "los angeles county".

Thanks guys,
@phrangque: A place, in my case, is an "area", therefore including "points" on a map. So it could be a state, could be a small village, or it could be a specific location like Google's headquater mentioned above.
@piatkow: My 2nd design would be the most normalized. But, you know, the more normalized it is, the slower the SELECT will be
@LifeinAsia: I'm not sure what you mean by the first sentence. You mean, by looking at one row alone, you can't figure out what sort of place it is?
If so, that's probably why the 1st design is preffered. But the DB will grow huge, and somewhat redundant.
For example, take the houses numbered from 1 to 100 on one street as an example. All of those 100 rows will contain exactly the information on country, state ...
I know hard disks are cheap but is this gonna cause a problem in this case?
Imagine, I want to store all the information of all the spots in the US. I don't know, but it could be say 1 billion rows for the 1st design, and a lot more number of rows for the 2nd design (but with less columns)

And I'm not sure which would be the best option for a scalable DB in this case?

For example, take the houses numbered from 1 to 100 on one street as an example. All of those 100 rows will contain exactly the information on country, state ...

I humbly suggest that you read up on normalisation and then heed piatkow's advice about creating a properly normalised data model, with emphasis on the term model [google.com]

Hello lavazz,
Actually, I have read about normalization. But I still don't know to which degree my db should be normalized or denormalized.

I am only extremely concerned with performance. One of the SELECT queries I might do, for example, is to find out the details of all the houses number 35 in California (in any street)

That's why I am asking here. Anyone please be kind enough to roughly suggest a schema?

(I hope i'm not so confusing..)

Reading up on third normal form might help

Please note: db design is NOT a trivial task

This does not mean it's 'rocket science' - but there IS a learning curve

Once you know the rules, you can break them (denormalise) for speed... but... I have a hunch that - even with a gazillion records, the benefits of denormalisation may well be not only negligible but also negated by increased maintenance costs (labour and time)

Whatever... learn the rules first, or hire someone who knows 'em already

:)

All of those 100 rows will contain exactly the information on country, state ...

There's nothing wrong with that per se.
It would be better to normalize it better like I said and have a States table and move the Country field to that table.

One of the SELECT queries I might do, for example, is to find out the details of all the houses number 35 in California (in any street)

If you're going to do a lot of queries like that (although I'm not sure why you would want to), then it would probably make sense to separate the number and street name into different fields in your table.

I will have a separate State table. So this is a kinda a hybrid between the 2 designs.

Thanks guys & happy new year!