I would conjecture that 7000 turns into 400k most likely because they are multipolygons. Think about the state of Hawaii as a single record with geometry. It has one geometry field, but there maybe dozens of polygons representing the islands within that one geometry field. I imagine archaeological data could have lots of small polygons.
It is a common problem to have too many geometries (or too complicated) to display quickly.
There are lots of ways to attack this problem --
- Services - create a map service from the data. It should have auto generalization. Be sure to set scale dependency to only show features when you need. You can create tiled map service -- for very fast display, but space and lack of feature attributes are trade off. Also, hybrid solutions of tiled and dynamic feature services.
- Client-side - when making individual graphics, you can display multiple features as a single cluster graphic at zoomed out levels. Google maps used to have this problem of bogging down when adding lots of individual graphics to browser -- clustering helps.
- Data - Spatialite and most spatial database or apps that access spatial data have functions to simplify (generalize) geometry. Spatialite has Simplify, SimplifyPreserveTopology. Don't know for sure but SimplifyPreserveTopology probably makes sure that no geometries disappear all together. What the alogorithms do roughly -- is reduce vertices in the geometry (you can look up Douglas-Peucker) by a tolerance. You'll have to experiment with tolerance.
Some stuff to go on...