"life is easier with the one big table": I've seen the natural consequence of this, being a 100+ column table, and I can tell you I find this no joy to work with.
The main problem is that the designers of such tables tend to omit the constraints required to ensure data integrity. For example, the OP says:
a journal reference requires both a journal title and an article title, and also a page number, whereas a book requires a publisher and a publication date which journal articles do not require
...which implies the following constraints:
CONSTRAINT a_journal_must_have_a_journal_title
CHECK ( type <> 'journal' OR journal_title IS NOT NULL );
CONSTRAINT a_journal_must_have_an_article_title
CHECK ( type <> 'journal' OR article_title IS NOT NULL );
CONSTRAINT a_journal_must_have_a_page_number
CHECK ( type <> 'journal' OR page_number IS NOT NULL );
CONSTRAINT a_journal_cannot_have_a_publisher
CHECK ( type <> 'journal' OR publisher IS NULL );
CONSTRAINT a_journal_cannot_have_a_publication_date
CHECK ( type <> 'journal' OR publication_date IS NULL );
CONSTRAINT a_book_cannot_have_a_journal_title
CHECK ( type <> 'book' OR journal_title IS NULL );
CONSTRAINT a_book_cannot_have_a_article_title
CHECK ( type <> 'book' OR article_title IS NULL );
CONSTRAINT a_book_cannot_have_a_page_number
CHECK ( type <> 'book' OR page_number IS NULL );
CONSTRAINT a_book_must_have_a_publisher
CHECK ( type <> 'book' OR publisher IS NOT NULL );
CONSTRAINT a_jbook_must_have_a_publication_date
CHECK ( type <> 'book' OR publication_date IS NOT NULL );
...and I suspect that's only the tip of the iceberg!
It's my hope that after writing several hundred such constraints the designer may have second thoughts about all those nullable columns :)
