views:

273

answers:

3

I'm starting a web project that likely should be fine with SQLite. I have SQLObject on top of it, but thinking long term here -- if this project should require a more robust (e.g. able to handle high traffic), I will need to have a transition plan ready. My questions:

  1. How easy is it to transition from one DB (SQLite) to another (MySQL or Firebird or PostGre) under SQLObject?
  2. Does SQLObject provide any tools to make such a transition easier? Is it simply take the objects I've defined and call createTable?
  3. What about having multiple SQLite databases instead? E.g. one per visitor group? Does SQLObject provide a mechanism for handling this scenario and if so, what is the mechanism to use?

Thanks, Sean

A: 

I'm not sure I understand the question.

The SQLObject documentation lists six kinds of connections available. Further, the database connection (or scheme) is specified in a connection string. Changing database connections from SQLite to MySQL is trivial. Just change the connection string.

The documentation lists the different kinds of schemes that are supported.

S.Lott
+2  A: 

Your success with createTable() will depend on your existing underlying table schema / data types. In other words, how well SQLite maps to the database you choose and how SQLObject decides to use your data types.

The safest option may be to create the new database by hand. Then you'll have to deal with data migration, which may be as easy as instantiating two SQLObject database connections over the same table definitions.

Why not just start with the more full-featured database?

HUAGHAGUAH
+2  A: 

3) Is quite an interesting question. In general, SQLite is pretty useless for web-based stuff. It scales fairly well for size, but scales terribly for concurrency, and so if you are planning to hit it with a few requests at the same time, you will be in trouble.

Now your idea in part 3) of the question is to use multiple SQLite databases (eg one per user group, or even one per user). Unfortunately, SQLite will give you no help in this department. But it is possible. The one project I know that has done this before is Divmod's Axiom. So I would certainly check that out.

Of course, it would probably be much easier to just use a good concurrent DB like the ones you mention (Firebird, PG, etc).

For completeness:

1 and 2) It should be straightforward without you actually writing much code. I find SQLObject a bit restrictive in this department, and would strongly recommend SQLAlchemy instead. This is far more flexible, and if I was starting a new project today, I would certainly use it over SQLObject. It won't be moving "Objects" anywhere. There is no magic involved here, it will be transferring rows in tables in a database. Which as mentioned you could do by hand, but this might save you some time.

Ali A
+1 for SQLAlchemy over SQLObject
Matthew Trevor
What do you think of the migration needs just to get to 0.5 of SQLAlchemy? http://www.sqlalchemy.org/trac/wiki/05Migration From the outside, this seems a little like a project in a lot of flux. As a user, does it seem that bad though?
torial
Regarding more concurrent DBs, do you recommend one over another for someone who has primarily SQLite and MS SQL Server experience?
torial
SQLAlchemy is very stable. If it seems like it is not, that is wrong. The changes between 0.4 and 0.5 are very very minor. Re concurrent DB's: If you know (and own!) MSSQL, use it. Otherwise PostgreSQL, and MySQL are good too. (I prefer Postgre).
Ali A