Comments on: marcdb http://inkdroid.org/journal/2007/10/01/marcdb/ beep beep Sat, 05 Jul 2008 19:08:59 +0000 http://wordpress.org/?v=2.5.1 By: inkdroid » Blog Archive » more marcdb http://inkdroid.org/journal/2007/10/01/marcdb/#comment-44619 inkdroid » Blog Archive » more marcdb Mon, 05 Nov 2007 17:14:27 +0000 http://www.inkdroid.org/journal/2007/10/01/marcdb/#comment-44619 [...] headings in the LC authority file. You know how it is. Anyhow, I remembered that I’d used marcdb to import all of Simon Spiro’s authority data–so I fired psql and wrote a [...] [...] headings in the LC authority file. You know how it is. Anyhow, I remembered that I’d used marcdb to import all of Simon Spiro’s authority data–so I fired psql and wrote a [...]

]]> By: ed http://inkdroid.org/journal/2007/10/01/marcdb/#comment-43437 ed Mon, 15 Oct 2007 13:08:40 +0000 http://www.inkdroid.org/journal/2007/10/01/marcdb/#comment-43437 I like this idea. Had you thought about what the queries would look like? Flattening like this is typical in data warehousing applications where the emphasis is more on reporting. There would be a lot of duplication of data, but I don't see that as a particular problem. But it might make queries that want to treat the record as a unit a bit problematic. Thanks for the feedback. I like this idea. Had you thought about what the queries would look like? Flattening like this is typical in data warehousing applications where the emphasis is more on reporting. There would be a lot of duplication of data, but I don’t see that as a particular problem. But it might make queries that want to treat the record as a unit a bit problematic. Thanks for the feedback.

]]> By: Xiaoming Liu http://inkdroid.org/journal/2007/10/01/marcdb/#comment-43317 Xiaoming Liu Thu, 11 Oct 2007 17:49:34 +0000 http://www.inkdroid.org/journal/2007/10/01/marcdb/#comment-43317 Thanks, this is nice and handy. Since the goal is to run easy SQL query, perhaps it make sense to bend SQL rule a bit to use less tables and joins? right now the schema using four tables, if it's reduced to one table: (recordid, tag, position, indicator1,indicator2, subfield, value) fol05731351, leader, ..... , 00755cam 22002414a 4500 fol05731351,008, .... 000107s2000 nyua 001 0 eng fol05731351,245,1,0,1,a, Perl (Computer program language) .... Thanks, this is nice and handy.

Since the goal is to run easy SQL query, perhaps it make sense to bend SQL rule a bit to use less tables and joins? right now the schema using four tables, if it’s reduced to one table:

(recordid, tag, position, indicator1,indicator2, subfield, value)

fol05731351, leader, ….. , 00755cam 22002414a 4500
fol05731351,008, …. 000107s2000 nyua 001 0 eng
fol05731351,245,1,0,1,a, Perl (Computer program language)
….

]]>