2008-11-09 11 views
1

Je démarre un projet Web qui devrait probablement convenir à SQLite. J'ai SQLObject au-dessus, mais en pensant à long terme ici - si ce projet devrait exiger un plus robuste (par exemple capable de gérer un trafic élevé), j'ai besoin d'avoir un plan de transition prêt. Mes questions:Modification de la base de données sous SQLObject

  1. Est-il facile de passer d'un DB (SQLite) à un autre (MySQL ou Firebird ou PostGre) sous SQLObject?
  2. SQLObject fournit-il des outils pour faciliter cette transition? Est-ce simplement prendre les objets que j'ai définis et appeler createTable?
  3. Pourquoi ne pas avoir plusieurs bases de données SQLite à la place? Par exemple. un par groupe de visiteurs? Est-ce que SQLObject fournit un mécanisme pour gérer ce scénario et si oui, quel est le mécanisme à utiliser?

Merci, Sean

Répondre

3

3) Est une question assez intéressante. En général, SQLite est plutôt inutile pour les contenus Web. Il s'adapte assez bien à la taille, mais il évolue terriblement pour la simultanéité, et si vous avez l'intention de le faire avec quelques requêtes en même temps, vous aurez des problèmes. Maintenant, votre idée dans la partie 3) de la question est d'utiliser plusieurs bases de données SQLite (par exemple un par groupe d'utilisateurs, ou même un par utilisateur). Malheureusement, SQLite ne vous aidera pas dans ce département. Mais c'est possible. Le projet que je connais qui a déjà fait cela est Divmod's Axiom. Donc, je vérifierais certainement cela.

Bien sûr, il serait probablement beaucoup plus simple d'utiliser une bonne base de données concurrente comme celles que vous mentionnez (Firebird, PG, etc.).

Pour être complet:

1 et 2) Il devrait être facile sans vous en train d'écrire beaucoup de code . Je trouve SQLObject un peu restrictif dans ce département, et je recommande fortement SQLAlchemy à la place. C'est beaucoup plus flexible, et si je commençais un nouveau projet aujourd'hui, je l'utiliserais certainement sur SQLObject. Il ne bougera pas "Objets" n'importe où. Il n'y a pas de magie impliquée ici, ce sera le transfert de lignes dans des tables dans une base de données. Ce que vous avez mentionné pourrait faire à la main, mais cela pourrait vous faire gagner du temps.

+0

+1 pour SQLAlchemy sur SQLObject –

+0

Que pensez-vous des besoins de migration pour arriver à 0.5 de SQLAlchemy? http://www.sqlalchemy.org/trac/wiki/05Migration De l'extérieur, cela ressemble un peu à un projet dans beaucoup de flux. En tant qu'utilisateur, cela semble-t-il si mal? – torial

+0

En ce qui concerne plus de DB simultanées, recommandez-vous un sur l'autre pour quelqu'un qui a principalement l'expérience SQLite et MS SQL Server? – torial

0

Je ne suis pas sûr que je comprends la question. Le SQLObject documentation répertorie six types de connexions disponibles. En outre, la connexion à la base de données (ou schéma) est spécifiée dans une chaîne de connexion. Changer les connexions de base de données de SQLite à MySQL est trivial. Changez simplement la chaîne de connexion. Le documentation répertorie les différents types de systèmes pris en charge.

2

Votre succès avec createTable() dépendra de vos schémas/types de données de table sous-jacents existants. En d'autres termes, dans quelle mesure SQLite correspond à la base de données que vous choisissez et comment SQLObject décide d'utiliser vos types de données.

L'option la plus sûre peut être de créer la nouvelle base de données à la main. Ensuite, vous devrez gérer la migration des données, ce qui peut être aussi simple que d'instancier deux connexions de base de données SQLObject sur les mêmes définitions de tables. Pourquoi ne pas commencer simplement avec la base de données plus complète?