I'm just after the basic concept for good database design.
'A Folio List' might not be a good name - I just couldn't think of what else to call it. I just mean a list of paper pages with the real data being their content.
What I've got is many pages, about 500, bound in loose leaf binders.
They have sheet music on them.
Some pages have more than one piece of music, more than one title.
And some titles have more than one page.
So do I:
1. Give unique page number and have maybe 6 fields for up to 6 titles per page, effectively listing pages or
2. Give unique numbers to each title and effectively list titles or
3. Have two tables with a many to many relationship - 'pages' to 'titles' Meaning three tables finally.
Point being, of course, it's virtually impossible that there'd be more than say six titles per page - to get six we'd be into something only half a dozen bars long like perhaps bugle calls. I realise the two tables is the classic relational database approach but real world, pragmatic, would it be the way to go here and now for me, for this application.
At the moment I've just numbered each page and am busy copying the details of which titles exist on which pages into a excel spreadsheet.
The 'two tables' approach doesn't work with Excel ( I suppose, though I wouldn't be surprised to find Excel experts indignantly claiming it's a snack to implement) but I'm proposing to stick it all into MySQL when I get to that stage.
'A Folio List' might not be a good name - I just couldn't think of what else to call it. I just mean a list of paper pages with the real data being their content.
What I've got is many pages, about 500, bound in loose leaf binders.
They have sheet music on them.
Some pages have more than one piece of music, more than one title.
And some titles have more than one page.
So do I:
1. Give unique page number and have maybe 6 fields for up to 6 titles per page, effectively listing pages or
2. Give unique numbers to each title and effectively list titles or
3. Have two tables with a many to many relationship - 'pages' to 'titles' Meaning three tables finally.
Point being, of course, it's virtually impossible that there'd be more than say six titles per page - to get six we'd be into something only half a dozen bars long like perhaps bugle calls. I realise the two tables is the classic relational database approach but real world, pragmatic, would it be the way to go here and now for me, for this application.
At the moment I've just numbered each page and am busy copying the details of which titles exist on which pages into a excel spreadsheet.
The 'two tables' approach doesn't work with Excel ( I suppose, though I wouldn't be surprised to find Excel experts indignantly claiming it's a snack to implement) but I'm proposing to stick it all into MySQL when I get to that stage.