Mixing geometry types, is there a cost when I come to querying it later?
I have a mysql table with a field of the type POLYGON, containing a number of polygons, however I have discovered I also need to store POINTS.
I'd like to store the geometry types POLYGONS and POINTS in the same field.
The manual page suggests this is possible, by using the data type GEOMETRY.
Are there any drawbacks to using the more generic geometry type GEOMETRY to do this? Will I be losing access to any extra functionality by mixing POLYGONS and POINTS when I come to query this data at a later stage?
EDITED
To clarify my situation:
I have a table call it 'locations'开发者_Python百科 each location will either best be described as a single POINT or an area a POLYGON but they will always have either one or the other.
So should the structure resemble:
locations:
id int
title var
single_point (POINT)
area (POLYGON)
or
locations:
id int
title var
coords (GEOMETRY)
or, as suggested in the comments below a 3 table solution?
The points and polygons will be baked into kml files in the first instance for display in web maps.
I envisage that the geometry fields will be indexed in order to make the best use of other spatial type queries in the future (nearest, largest area and so on).
The way I have traditionally done this is to have 3 tables:
locations:
id int
title varchar(100)
location_points:
id int (FK to locations)
point_coords POINT
location_area:
id int (FK to locations)
poly_coords POLYGON
You could then create a view that would mimic your two-column table design:
SELECT loc.id AS id, loc.title AS title,
p.point_coords as single_point, a.poly_coords as area_poly
FROM locations loc
LEFT OUTER JOIN location_points p ON loc.id = p.id
LEFT OUTER JOIN location_area a on loc.id = a.id
WHERE a.id IS NOT NULL OR b.id IS NOT NULL;
精彩评论