>Here are some things I'm considering, please let me know your opinions on these:
>
>1. Everything I've read on clustering SQL Server or MySQL has really turned me off. It seems like it's not too hard to setup failover OR scalability, but combining fail-over and scalability gets way more complex, not to mention expensive.
--> It isn't the easiest thing to do but it works well. OTOH I have very large (70+GIG) mission critical medical databases deployed on single SQL 2005 server boxes that have run flawlessly for years. I have never felt the need to use a cluster.
>
>2. It seems like a SAN puts all the complexity in one place and then everything else can be dumb.
--> Not when it comes to a database. VFP databases have too many inherent drawbacks - corruption, broken indexes,security, scalability, bloat, need to pack, etc. It's nice to have a reliable network. It won't make a difference when the database is broken.
>
>3. I've never had any data corruption issues on quality networks. If a table does become corrupt Abri makes a great recovery tool.
--> I've had enough that I abandoned VFP tables many years ago. I've migrated many VFP systems to SQL Server backends over the last 10 years and nobody has regretted it.
>
>4. I've always read/heard that a SQL server for a small user base is actually slower than a file based .DBC
--> Perhaps if it is a very small database. Otherwise SQL Server on a reasonable box will run circles around it.
>
>5. A SAN, once in place, is very easy to scale up or out.
--> They are nice if they are decent hardware. If they are fast enough the SQL Server database can reside on them.
>
>6. To scale out the web server side, just add cheap 1u web servers.
>
--> I don't have enough experience with server farms to offer an intelligent opinion on that.
>
>Thanks,
>Brandon
____________________________________
Don't Tread on Me
Overthrow the federal government NOW!
____________________________________