Not sure if associating each tile to its type should be a major concern in terms of execution speed. You'll only be doing this when the game loads, not on every frame. Regarding how I'd do it:
I would define simple rectangle structures in case there are none defined in your environment:
structure Rect has components:
XPosition : integer
YPosition : integer
Width : integer
Height : integer
and extend this to:
structure AreaTypeRect has components:
<components from Rect>
AreaType : symbol
And store them in a SQL (since you're using it) table. Map each rectangle to the level it belongs to with a foreign key.
Basically, the rectangle with XPosition = 5, YPosition = 5, Width = 10, Height = 10 means the tiles in the rectangle defined by the points (5, 5), (5, 15), (15, 5), (15, 15).
Why did I define AreaType as array? You may define it as a single value-type if you absolutely won't need terrain type blending. But you might reach some nice effects with multiple types per tile. For example, you could mark a particular tile to be of the type Grass and then add the type Water to it. This could result in a Grass tile with some Water stains on it, as if it rained a lot.
I might be overthinking this though. Perhaps a single AreaType per tile is enough for your needs.
AreaType can be any kind of symbol, but you must tell your game how to interpret it. I would go with integers and map them like this:
(integer AreaTypeID, Texture TileSprite)
or with colors, as you mentioned you'll be using in the editor (blending colors from multiple terrain types is even easier):
(integer AreaTypeID, Color TileColor)
You can do this mapping in a SQL table, if you do store things such as textures in the SQL database. I'd store artwork on the hard drive though.