I am about to start my ROR adventure, I have purchased 6 books on the subject (including the sitepoint one) and I'm ready to get stuck in.
Before I start what is the best way to install ROR on windows, the installer I am looking at installs SQLite and Apache.
1: If I have Apache already installed to I need to remove it before this install
2: Why are they using SQLite and not MySQL. When I eventually go to production on a live server will SQLite be the default used by most of the hosting companies.
If anyone else has any tips I would love to hear them.
2) SQLite is fine for you to develop and test your apps on your own machine as a single user so you're up and running straight away.
As you have different entries for your production database details in database.yml you can easily put in separate details for a MySQL database. You will likely have a MySQL server set up on your web host for production rather than SQLite.
You can keep using SQLite on your own development machine until things get complicated (ie, you're getting database specific) as Rails does the database abstraction for you. Why make it any harder? (Paraphrased from Agile Web Dev with RoR.) Personally I use MySQL locally just because I use phpMyAdmin a lot to browse around and run ad-hoc queries.
You can develop complicated applications. But you know, the usual stuff is the same across all reasonably good databases. I meant complicated as in using db server specifics like sizes of data types, built in functions, specific storage engines, etc. But your usual get this record, get all records related to it, update that record, etc, which is the bread and butter of web apps will work with any db.
Rails will (re)build the database structure from scratch using its own migrations system. You might want to use the same db if you are trying to duplicate (ie export / import) the data regularly from development to production.
Anyway I am quite new to RoR myself but I'm pretty sure the gist is use SQLite until you need not to. At worst you export from one dbms into another when you finally switch. Hopefully somebody more experienced will chip in . If I know what I'm talking about, you don't want to use SQLite in production because it's not very concurrent and there's a chance you can lose data if two users make requests on it at the same time.
It's possible to develop a complicated app in SQLite, I just wouldn't expect it to stand up to high traffic.
But you can develop using any db, and go into production with another db. Just be aware that if you write any SQL of your own, that what works in one db may not work in another. 99% of it will, but that 1%....