[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Why not SQL for the backend?

From: Barry Scott <barry.alan.scott_at_ntlworld.com>
Date: 2002-02-07 01:42:01 CET

I'm well aware of OODB technology. I have worked on Versant and
Objectivity as well relational DB PostgreSql and SQL Server.

My primary concern is getting a serious database and query capability.

Why do you think that a relational database would be a problem?

I can think of reasons like quality of BLOB support that might make it
harder to use certain DB. (e.g. PostgreSQL BLOB is to and from local
disk on the DB server not the disk of the client.)

                BArry

-----Original Message-----
From: Marcus Comstedt [mailto:marcus@mc.pp.se]
Sent: 27 January 2002 13:57
To: dev@subversion.tigris.org
Subject: RE: First impressions...

Barry Scott <barry.alan.scott@ntlworld.com> wrote:

> Using a database is far more powerful then using a file system.
>
> Being able to use SQL to query the repository is a good solution
> to building the more complex SCM solutions on top of SVN.
>
> My guess would be that folks that want the database backends
> have tackled complex SCM problems and know why the simple interfaces
> to meta data have problems. Speed of query across large sets of
> versions and files being one.

Don't make the mistake of puting an == between "SQL" and "database".
SQL implies a _relational_ database, which I think is totally out of
place here. A hierarchical or object database seems far more
appropriate.

  // Marcus

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.