faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: why postgres?
by Scott Wheeler on Wednesday 23/Feb/2005, @09:13
|
Well, Postgres is the third database that I've tried. I did the original mockup prior to the KDE conference this summer with SQLite and the performance for the type of queries that we're doing was so bad that it simply isn't an option. Also SQLite is really only designed to be used from a single process, so we'd have to implement locking and multi-user access in a daemon on top of it, which, well, at that point you're just implementing a database server, really, but without the performance of more robust databases.
So I then ported that mockup to MySQL, which performs fine, but is GPL'ed rather than LGPL'ed. As performance is similar for MySQL and Postgres, but Postgres has more flexible licensing (i.e. suitable for use in things linked to kdelibs) Postgres wins there.
WinFS is something completely different. It's what's called an Attribute Value System or object database -- and it's only being used for "My Documents", not the complete FS. What we're working on isn't something that's going to replace parts of the FS, it will supplement it with contextual information. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: why postgres?
by Marco Menardi on Wednesday 23/Feb/2005, @13:39
|
Have you ever tried FirebordSQL? It's a true database server, ACID compliant, multiplatform, license is a modified versions of the Mozilla Public License (so unfortunatly no pure GPL), takes relly few resources and is developed by an active community:
http://www.firebirdsql.org/
"Firebird is a relational database offering many ANSI SQL-99 features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers"
|
[
Reply To This | View ]
|
Re: why postgres?
by AC on Wednesday 23/Feb/2005, @13:50
|
MPL isn't GPL compatible; there's not even a reason to look further. We're going to have to use the client libraries for these databases.
I don't see any reason not to use Postgres; there are loads of ways that all of this could be done, but the datastore is the boring part and Postgres fits our requirements. I don't really see a reason to look further at the moment.
|
[
Reply To This | View ]
|
Re: why postgres?
by Scott Wheeler on Wednesday 23/Feb/2005, @13:53
|
Err, that was me. Konqueror is having fun with my cookies.
|
[
Reply To This | View ]
|
Re: why postgres?
by Marco Menardi on Wednesday 23/Feb/2005, @15:01
|
I've never heard of problems with FirebirdSQL and GPL, since you have to connect with the database, not include his code. Maybe their "modified" MPL is modified enought to be able to interface with GPL programs ;) But I'm not a lawyer.
I was replying to your message about PostgresSQL vs MySQL, and I'm sure you will be surprised on Firebird performances, low footprint, high stability, low manteniance needs, etc..
So mine was just a suggestion, since if you "don't see any reason not to use Postgres", I don't see any reason to use Postgres instead of Firebird ;)
So would be great if you could have a look also at Firebird :)
thanks
|
[
Reply To This | View ]
|
Re: why postgres?
by Ian Monroe on Thursday 24/Feb/2005, @00:11
|
Well, I'd assume the client libraries for FirebirdSQL are in MPL as well. You do have to link againist those.
|
[
Reply To This | View ]
|
Re: why postgres?
by Marco Menardi on Thursday 24/Feb/2005, @01:00
|
Well, I use Firebird and, at the moment, my program is in Delphi under Windows, so I'm not an expert and I don't know what "client libraries" you need.
I know, for instance, that JCA/JDBC Driver:
http://www.firebirdsql.org/index.php?op=devel&sub=jdbc
is distributed free of charge under the GNU Lesser General Public License (LGPL).
I don't know about ODBC/JDBC Driver
http://www.firebirdsql.org/index.php?op=devel&sub=odbc
or ADO.NET Data Provider
http://www.firebirdsql.org/index.php?op=devel&sub=netprovider
but probably the license is included in the package you can download.
In any case, if you visit the main site I suggest you http://www.firebirdsql.org/ probably you can understand more and better.
Thanks again
|
[
Reply To This | View ]
|
Re: why postgres?
by brockers on Thursday 14/Apr/2005, @16:39
|
So KDE is going to choose a database that is LGPL because of licensing restrictions from using a straight GPL'ed database when we use a GPL'ed toolkit to do EVERYTHING related to Qt? I hope this is not really the case because it would seem to lend credibility to the Gnome-huggers who say that KDE is worthless as a general purpose business desktop because QT is GPL'ed and not LGPL'ed. If we can use QT in KDE why not MySQL? Don't get me wrong, I don't have a problem with Postgres, I just hate to see KDE use the same argument against something that has been leveled against us.
|
[
Reply To This | View ]
|
|
Have you looked at MetaKit?
by Mr. Fancypants on Wednesday 23/Feb/2005, @14:08
|
(See http://www.equi4.com/mkdocs.html)
It seems to support most of the usual relational operators without the yuckiness (quoting differences, various conventions for parameters, non-standard syntax, etc.) of SQL.
There also seems to be support for concurrent reading and writing (maybe only 1 writer at a time, I'm not sure) and it looks quite mature.
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by ac on Wednesday 23/Feb/2005, @14:43
|
Please stop listing existing databases.
I'm sure that Scott and Aaron know that there are many DBs out there.
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by anon on Wednesday 23/Feb/2005, @15:20
|
We're using in akregator now. metakit is very good.
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by Aaron J. Seigo on Thursday 24/Feb/2005, @00:17
|
as an embedded database it looks good. but we don't need an embedded database, we need a database that can be accessed simultaneously and, preferably, over a network. the TODO list for this project is already big enough without adding "write a scalable RDBMS" ;)
once the first edition is out using an external RDBMS then perhaps all the data storage fans can swoop in with their super dooper file systems and coolio ultra-tiny database-like engines and experiment/optimize that area of the software.
but it's not the interesting nor a critical part of the project. =)
|
[
Reply To This | View ]
|
Re: Have you looked at MetaKit?
by Pat on Thursday 24/Feb/2005, @07:49
|
maybe u could make the data storage part "pluginable" so that developpers could easily implement different db backend à la kexi or even like that damn amarok while you could focus on the postgresql part :)
|
[
Reply To This | View ]
|
|
Re: why postgres?
by Carlo on Wednesday 23/Feb/2005, @14:11
|
Oh well, please stay with Postgres and don't give a flying fart on those wanting sqlite or some java based db. Very good choice!
|
[
Reply To This | View ]
|
Re: why postgres?
by muesli on Thursday 24/Feb/2005, @07:34
|
hey scott!
we (amarok) have dealed with quite all sqlite issues you could imagine ;-)
so, let me assure you, that i still believe it could be used, but some simple things have to be done:
a) you can set a threadsafe variable in the Makefile. this will help improve the situation!
b) why not use a singleton interface for searching? this way you can take care of the locking easily. if you need code: look at collectiondb.cpp/.h in amarok/src. there is even a connection pool n everything. that is also useful for other db interfaces, even though i dunno what qsql offers wrt this issue.
c) most sqlite issues can be easily solved by setting proper indices. when you do that, sqlite is barely slower than mysql. although, one must admit that there are more situations where sqlite is not able to use an index at all.
anyways, mysql or postgresql is to have imho. reconsider sqlite! it's worth the little hassle.
regards,
muesli
|
[
Reply To This | View ]
|
Re: why postgres?
by muesli on Thursday 24/Feb/2005, @07:36
|
"anyways, mysql or postgresql is to heavy imho. reconsider sqlite! it's worth the little hassle."
s/have/heavy ;-)
...muesli
|
[
Reply To This | View ]
|
Re: why postgres?
by Scott Wheeler on Thursday 24/Feb/2005, @08:06
|
> we (amarok) have dealed with quite all sqlite issues you could imagine
Honestly I doubt it. amaroK is a very simple application (in database terms) relative to what we're working on. A music player with a couple MB of data is a very different beast trying to store and query graphs in a database that may easily grow to a few hundred MB.
> why not use a singleton interface for searching?
Because that's only useful for one process.
> most sqlite issues can be easily solved by setting proper indices
Not for heavy use of cross table selects on interrelated values. I literally had several queries that took 15 minutes on SQLite that were done in less than 1-2 seconds on PGSQL or MySQL. And that was just on a 10 MB test database. I'm not saying that the limitations of SQLite couldn't possibly be worked around, I'm just saying that there's no compelling reason to work around them when there are better databases available that already solve these problems.
SQLite also locks the entire database on write, which just isn't acceptable in a tool used frequently by multiple processes.
Basically, as Aaron already said -- it might be possible to work around all of the issues with SQLite. But in the end we'd just be implementing the features that other databases already provide and we'd need a daemon process anyway to handle communication with it, which, well, makes no sense.
|
[
Reply To This | View ]
|
Re: why postgres?
by Carlo on Thursday 24/Feb/2005, @11:46
|
I'd rather like to see Amarok integrate in such a new framework, instead that every application has it's own db. E.g. to access covers and the correspoding metadata with Digikam, without having to add a new album in digikam and the metadata stored twice.
If it would be possible to specify something like "apply <filter> on amarok:covers which are smaller than (x,y), jpegs and greenish, pipe result to <dialogX>,[...]", without having joe user to think about what the hell he is doing... ;)
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|