Alvaro,
> Now, I'm building a database to hold customer data that needs to be
> organized in a one-table-per-customer manner. No, I don't think there's
> another way to do this
Maybe, there's still a way to implement this in a theoretically correct
manner? In fact, the amount of data (meaning cardinal number, I guess)
doesn't matter that much.
Of course, you can always query data dictionary (system tables) to find
out whether particular table exists, but you're not guaranteed to have
these tables always the same, little bits may change between releases.
You can split large tables `horizontally,' ie store relatively old data in
bigger, `archive' tables, and newer data in smaller, `live' ones.
--
contaminated fish and microchips
huge supertankers on Arabian trips
oily propaganda from the leaders' lips
all about the future
there's people over here, people over there
everybody's looking for a little more air
crossing all the borders just to take their share
planning for the future
Rainbow, Difficult to Cure
