Saving data as a whole vs saving data in scattered mode

Question

Please, if you think this question is too broad, tell me if there's a name for this kind of problem in order to google it.

I've been developing and maintaining a web application for a couple of years and I've come up with scalability problems, specificly on how to save data from a data model.

To simplify, let's suppose the web application is a database of novel writers. Initially the model was very simple and updating information was easy: a form was displayed and the user could enter the author's name and biography and then click on the "Save" button to store the information into the DB.

Now, let's suppose I want to add a "Book List" in the author's page so I can add the books the author has written so far. How is the application supposed to work now? Should I keep a list of books in a Javascript array (for example) and then send everything (name, biography, books) to the server when I clicked on the "Save" button? Or should I just update the book list separately from the author's basic info (i.e. when the user adds/updates/removes a book from the list). In such case, wouldn't the "Save" button be confusing for the user?

EDIT

The Javascript comment above is just an example to explain my case. By "scattered" I mean "spread". Books are actually a piece of information that belongs to an author, but one could even attach more information to an author as the application scales (via add-ons for example). Let's assume books and other future stuff related to an author is not independent of the author entity. As the amount of information grows a single "Save" button can be resource consuming (e.g: biography should not be updated if we just added a book to an author). My problem focuses the way data belonging to an entity must be committed to the server: should all information be saved at a time when the user clicks "Save" or should every piece of information be saved independently (perhaps with independent save buttons)? Think about Microsoft Windows vs Macintosh OS X control panel: whereas in Windows you have a "Accept/Cancel" paradigm, in Mac OS X changes are applied when you change each setting (there's only a "go back" or "close" button).

Answer 1

The problem seems to be related to the (third form of) database normalisation. Each rerasonably disjunct set of data (like information about a book) should/could be editable on its own without the user's need to touch any other set of data (like the author page)

In general you want to decide what information belong together and make it visible to the user that they edit all of them at once or only a single data.

For your example you could have an author with a list of his books (title, release date, ..) and make the book fields editable as well as adding a button to edit this book
the button could open another window with only the book details, these data would then be transferred to the original form and the user still has the option to save or discard the changes.

A setup where you could change and save data inside a form meant to change and save data is confusing.