aleax at aleax.it
Thu Mar 6 11:46:44 CET 2003
Dennis Lee Bieber wrote:
> Eliran Gonen fed this fish to the penguins on Wednesday 05 March 2003
> 04:22 am:
>> Alex Martelli <aleax at aleax.it>:
>>> That depends on your purposes and on the size the database
>>> is likely to grow to.
>> A list of books, ability to locate books, remove/add entries.
>> No more than 200-300 books (perhaps even less).
>> This seems to be nice, as I don't need any complexity.
>>> and "parse" this with [ rec[:-1].split('|') for rec in afile ].
> Of course, now how do you handle a book with multiple authors,
> each of
> which have multiple books <G> Lots of duplicate data in that case.
Not really, since the OP didn't specify he'd have any data about
book authors. So, each book-author is a simple string token, and
the field devoted to listing a book's author[s] (2nd field in the
above scheme) a concatenation of such strings into a larger string
(using a joiner that doesn't appear in any of the string tokens of
interest, of course). Where's the "duplicate data" where you
indicate e.g. 'Matt Ridley' as the author of one book, 'Mark Ridley'
as the author of another, and both strings joined by (e.g.) a
semicolon at the author[s] of a third [should these two excellent
near-homonym authors of evolutionary biology popularizations
ever decide to collaborate and further increase the typical
Much as I adore the relational model, normal forms, etc, it makes
little sense to deploy them all for a "database" that's a single
table with a couple of hundreds of small entries, as per specs...
More information about the Python-list