Thanks Steven for the suggestions. For me, database schema definitions can
come later. What we should decide on first is the different pieces of data
that we should be gathering while working through our sources (Gramophone,
Myers Index, Schwann, etc..). Certainly the following:
record catalog number,
reference publication name,
reference publication year, month, day,
reference publication page number(s),
My gut tells me that we should go ahead with gathering recording information
as it is available when found, like composer, conductor, orchestra,
composition, etc.... what else?
D. Blake Werts
----- Original Message -----
From: "Steven C. Barr(x)" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Tuesday, December 19, 2006 12:18 AM
Subject: Re: [ARSCLIST] Fwd: [ARSCLIST] Dating LPs ?
> ----- Original Message -----
> From: "D. Blake Werts" <[log in to unmask]>
> > I do understand that there is a smattering of information here and there
> > with regards to classical LPs. And I have a couple of the guides that
> > reference with respect to microgroove LPs and I have not found "release
> > dates" for the discs themselves.
> > Maybe I'm still too naive: my goal is to be able to have all of this
> > information in a single, consistent, reliable, searchable database.
> 1) Create a database (MS Access works well) with a set of tables...one
> for each numeric series on each label.
> 2) The table format should be as follows
> (tables will be <label>01 up to <label><max#>
> NUMBER see note below
> YEAR Integer
> MONTH Integer
> (NOTE: to make numbers sort properly, use three fields: NPFX(text),
> NUM(integer), NSFX(text)...so KSM-30544-ST is broken up into three
> entries, and a query sorts the three in order (thus KSL's all come
> before KSM's regardless of number, and KSM-30544-QD sorts before
> the example entry...).
> 3) Complete data records as you find data...you can decide whether
> to use Monthly, Bi-yearly (like my Dating Guide) or a different
> system after looking at data found and table sizes.
> 4) Having completed as many tables as necessary/possible, the
> data can now be converted to HTML, exported to Excel or MS Word,
> or whatever...
> Steven C. Barr