Unless you have need to be able to apply relational algebra to the data, a simple and very fast approach is to simply store the data in a series of dynamically extending linked lists using some fairly rudimentary block oriented buffer management and linked list code.
It's a commonly used general architecture for storing data that requires near realtime access (have used it dozens of times for everything from realtime message switching systems to sub-second response transaction systems to low latency data processing systems to applications needing dynamically retrieved/updated object archives).
For your specific use, it allows you to store an effectively unlimited amount of price data for each symbol with the absolute minimum # of disk accesses needed to load any given dataset on the fly without the additional overhead that a traditional SQL database would incur. It can be tweaked for specific performance requirements by using variable cluster size, memory caching, hashing, etc.
If near realtime/low latency data access isn't an issue (and since you're unlikely to have the kind of high volume/high speed requirements of the systems I noted above), you could probably just store the price data in an ordinary SQL table, i.e., symbol (or alternatively a binary symbol ID - referenced from the symbol table), date, time (for intraday data only), open, high, low, close, volume, etc. and then use a normal SQL Select statement to retrieve and process any given symbol's price dataset (primary key would be symbol (or binary ID) plus date (plus time if it's intraday data). Definitely no need (or technical desire) to have to use a separate table per symbol.
As with any application, exactly what you intend to do with the data, how often you'll access it, and what your performance requirements are will be what dictates the target architecture - there's no generalized, one size fits all solution that solves every potential application.
