#musicbrainz

No problem. Ask a question next time. :)

:P

Also, CatCat, brianfreud, I actually bothered to put trans*terated on this time. ;p

MrQwerty] is now known as MrQwerty

It's depressing how many on there are /exact/ duplicates.

hihi, i'm right listening to the disc on the very bottom of that list.

/right/right now/

FauxFaux: how often / when does your dupscan page get updated? (i just 'fixed' one by adding a translated AR).

Knio1 is now known as Knio

Hi

Have you read this? I wonder if it would be beneficial to MB to have one column oriented copy for reading and a row-oriented "master" for edits... http://www.databasecolumn.com/2007/09/one-size-...

Or would it be just a big waste of space?

well i read it and i thought the same

I don't think edits need to show up immediately to users who just query the DB - besides edits need to be voted

And if I remember correctly, the disk space required for MB isn't an issue

a read-only (query only) server could be much more optimized, couldn't it?

I wonder what last.fm developers would have to say on that topic...

Isn't muz one of them?

i is in ur computer faulting segments

yeah and it caused aankhen to reboot

damn i have SQL headaches myself at

atm*

i was really looking into the column based databases, and am testing an implementation of D atm

copper: eh?

aaahhhhhh it's so relieving that Dr. Who doesn't have these f*cked and so loved cliffhangers from US TV shows

that's so braindead

also the xmas special is cute

Muzzz: I was wondering how appropriate column-oriented DBs would be to MusicBrainz, and was hoping for some insight based on your experience with last.fm - http://www.databasecolumn.com/2007/09/one-size-...

Ah, DB work like that isn't my forte, I just run the queries and do various other stuff

I don't actually set up the database, and maintain, so I'm the wrong guy to ask :)

ok

what are the advantages of column based storing?

fast reading

(but slow writing)

if you mainly read the data of one (or a few columns) for long lists, right?

given all the datamining going on at last.fm I'd assume column-oriented DBs would be even more beneficial to them

outsidecontext: right

it also compresses very well

copper: given the massive amount of writes we do, the large number of different databases, that'd be a silly assumption to make

A common misconception is that the charts are stored in a db, which they're not really

Muzzz: I thought maybe using different types of DBs for different applications would help?

copper: then my guess would be that this is not so beneficial for MB. there are a lot of edits and display of single or just a few rows

ok

I also seriously wonder how well that idea scales

copper: but that's only a general "feeling" :-) a look into the actual database queries would be better

May look to work great on a table with thousands of rows, but how's about millions heh

Muzzz: why would it scale less well than row-oriented DBs?

outsidecontext: the idea was to duplicate MB's DB into a column-oriented DB on a separate server for queries, and an edit-only row-oriented DB

I'm not saying it *would* be better, only wondering if it would :)

copper: ah. interesting idea. don't know

the major argument being that edits don't show up immediately anyway, since they need to be voted

(it might be a different story for last.fm though)

for what it's worth, the existing DB for MB wouldn't need to be changed

if there's a failure with the read-only DB just revert back to the "master" DB

copper: hm, most add edits show up immediatly. and pending edits, while not showing up as such, are marked with a different background-color:, etc..

yeah I knew about that, just thought I could live without it

please no :)

lol, why not?

when i see an album in need of lots of fixes, i tend to go in and fixit.

if the tracklisting is yellow all over, probably someone is on it already.

surely frequent editors must be a minority - they could use the master DB

the idea is to direct the bulk of users, doing mainly queries, to a faster read-only DB

ok, i'm just stating that I could not 'live without it'.

lol, ok :)

anyway, back to work :)

yeah them lines ain't going to code themselves ;)

(or whatever it is that you do for a living)

yes. code. php. and I have a deadline today.

brrr. php.

warp: poor guy

good afternoon

copper: One thing to notice is that the writer is founder of Vertica.

copper: So it's no wonder it sounds good to him.

And it starts with, IMO, false assumptions, so I'm inclined to take it more as marketing than anything else.

(Anyone taken a look at Oracle/DB2/pickanydatabase innards lately?)

can someone yes this? http://musicbrainz.org/show/edit/?editid=7485397

done

Done

thanks

done

hi all

FauxFaux: that reports result is ugly

but the report itself is jum!

hiya warp

jesus

there is 4 albums here that are dupes

*identical*

copper: main reason I don't buy into that article is, it only takes 3 of the 5 large db's into account, the 3 that support his point, not the ones that are counter to his "historical reason why it is this way"

whoooo: http://musicbrainz.org/show/edit/?editid=7486535

nice, a quartet! :)

boo

Moose.

welcome back aCiD2 :)

thanks :)

Have I missed much?

Not really

Just a drop table trm; statement

hey, for any of the UK folks - have an incomplete track title here. Who was the brother king who took over from King Edward VIII?

George VI

Thanks

working on a "greatest moments" speeches type of set

I wonder if a SPA [News Report] would make for more differentiation (and easier fixing down the road) than just [Unknown]

any comment on the recent last.fm tagging/voting development?