The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Hybrid View

SQLite & Apache question for ROR

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.

Two questions:

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.

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%....