MySQL embedded? The future of our database?

Mark Kretschmann kretschmann at kde.org
Fri Sep 7 19:27:20 CEST 2007


Hey Amarokers,

I just had this interesting discussion with Hydrogen on the future of
our database. I hope you don't mind me just pasting the IRC log; I
think it's more insightful than summarizing the content:

18:48 < hydrogen> speaking of one database
18:48 < hydrogen> has anyone investigated mysql embedded further?
18:56 < markey> yes, sort of
18:56 < markey> well
18:56 < markey> first of all I tried to gather some information about it
18:56 < markey> that wasn't a nice experience
18:56 < markey> only info I found is on the mysql.com site itself
18:56 < markey> which is horrible
18:56 < markey> (marketing speak)
18:57 < markey> then I tried to download the thing
18:57 < markey> also horror show
18:57 < markey> there's a 15mb package on mysql.com
18:57 < markey> no source code in sight
18:57 < markey> I'm not even sure what the license is
18:57 < markey> this seems to be some kind of evil stepchild of mysql
18:57 < markey> it didn't seem very open source like or well supported
18:58 < markey> your mileage may vary
18:58 < hydrogen> yea
18:58 < hydrogen> I was just looking kind of at it
18:59 < markey> it's not like sqlite where you download a tiny source
code package and put it in amarok's svn
18:59 < markey> that won't be possible with mysql embedded
18:59 < markey> we have to rely on distros packaging it
18:59 < markey> as a dependency
18:59 < markey> on windows I have no idea how we could use it
19:00 < hydrogen> that doesn't make sense..
19:00 < hydrogen> relying on distro's to package an embedded version?
19:02 < markey> embedded doesn't necessarily mean included in the source tarball
19:02 < markey> embedded means in-process
19:02 < markey> as opposed to external server
19:02 < markey> we could also depend on sqlite
19:02 < markey> instead of putting it in our svn
19:03 < hydrogen> mm
19:03 < hydrogen> true
19:04 < hydrogen> well
19:04 < hydrogen> that sucks!
19:04 < markey> well those were my initial findings
19:04 < markey> I only spent like 30min researching this
19:04 < markey> maybe the situation isn't that bad
19:04 < markey> it's just, the mysql site sucks so horribly that I
can't find any real information there
19:05 < markey> it's the most buzzword loaded site I've seen in my life
19:05 < hydrogen> yea
19:05 < markey> worse than microsoft
19:05 < markey> frankly it makes me dislike mysql
19:05 < markey> they are very very commercial
19:05 < hydrogen> hmm
19:05 < hydrogen> http://www.postgresql.org/docs/8.0/interactive/ecpg.html
19:06 < hydrogen> and they are rolling it out for windows
19:06 < hydrogen> or maybe already have
19:06 < hydrogen> yea
19:06 < hydrogen> they have
19:06 < markey> sounds interesting
19:06 < markey> but how mature is it?
19:07 < hydrogen> no idea
19:07 < hydrogen> i just googled it :)
19:07 < markey> we need a *reliable* solution in about 3 months time max
19:07 < hydrogen> I know postgresql is mature
19:07 < hydrogen> and opensource friendly
19:07 < hydrogen> both of which are positives
19:07 < hydrogen> we could try adding it and fleshing out the
postgresql collection backend
19:07 < hydrogen> and always have sqlite if it doesn't work out
19:07 < markey> I almost tend to say: let's go sqlite only, and try to
optimize for it
19:08 < markey> apart from the scaling issue, it's perfect
19:08 < markey> (and the regressions)
19:08 < hydrogen> yea
19:08 < hydrogen> more and more people have gigantic collections though
19:08 < markey> maybe our queries just suck, I dunno; I'm not a database expert
19:08 < hydrogen> you know more than me
19:09 < hydrogen> :)
19:09 < markey> google says that sqlite has great performance
19:09 < hydrogen> thats relative though
19:10 < hydrogen> although
19:10 < hydrogen> more to the point
19:10 < hydrogen> with strigi becoming part of the kde session
19:10 < hydrogen> I wonder if we could just query its database
19:10 < markey> well what db is strigi using?
19:11 < hydrogen> uhh
19:11 < hydrogen> nfc? :)
19:11 < markey> and I really don't think strigi is mature enough to
replace our scanner/collection in the short term
19:11 < markey> our solution is mature

-- 
Mark


More information about the Amarok-devel mailing list