Re: Choosing a database for a large amount of data

If you use Visual FoxPro, you can write it to work with .dbf's to begin with, then change it to access SQL, Oracle, or other databases without rewriting any code. This is a huge plus to Fox as a data manipulation engine. You'll need to use local views to achieve the 'switchability' without recoding. You would later convert these to "remote" views, which access SQL data through OLE-DB. You can write an app to "switch" like this either in a COM object, or where the GUI is written in Fox.

If you're looking for a low-cost, high-performance database, you won't find anything better than Visual FoxPro. However, it doesn't have a high level of data security like a SQL database will. That's a trade-off you'll have to consider when choosing a back-end.

• Bruce Allen
• Left Brain Incorporated

kurt wood wrote:
>
> A couple possible solutions. First off, dump Access. It is nothing more
 than a
> toy when it comes to doing real database work. It may be fine for you X-
 mas card
> list, but that's about it...
>
> 1. If you a an "all-in-one" solution, try Visual FoxPro. It can and does
 handle
> well over a million records fairly quickly. This may be an especially
 good
> soluion if you are the only user and it is not being run over a network.
>
> 2. If you expect this this to get very large (10's of millions of
 records), then
> you will have to use an SQL database like Oracle or DB2. (btw, look at
 IBM's web
> site . There you can download a free copy of DB2 Personal edition..)
>
> Demetrio Trombi wrote:
>
> > Hi All,
> >
> > I was wondering whether some of your more experienced folk might point
 me in
> > the right direction. I have constructed a large database with stock
 market
> > information that I use to import into Excel with its charting
 functions. At
> > present I use MS- Access and have over 90,000 records with 7 fields -
> > Processed file ID, Company Code, Open, High, Low, Close, Volume. This
 is for
> > approx 1.5 years of history and my goal is to have around 10 years.
 Already
> > though, querying this database takes several seconds and it has
 occurred to
> > me that there must be a more efficient way as I have noticed that even
 over
> > the internet I can get web pages to display charts quicker than I can.
 And
> > as, in the future, the database will get larger and larger this will
 only
> > make things slower. I have tried to create a different tables in the
 same
> > database that represents each company but this really didn't do much.
 What
> > do you think? Perhaps another type of database or another system. I'm
 not
> > very experienced with the different type of packages available so
 please any
> > info. will help.
> >
> > Thanks,
>

--
Posted via CNET Help.com
http://www.help.com/