Не обязательно. Если ты принимаешь решение, что даже LONGTEXT может не вместить данные, то просто добавь еще одно поле в таблицу. В нем записывай порядковый номер загруженной части данных. То есть, числа 1, 2, 3... При выборке, соответственно, указывай сортировку по возрастанию по этому полю.
Если же данные убираются в одну запись, то пиши там 0. Это будет четким индикатором того, что не надо читать другие записи.

Но вообще, я смутно представляю, что такое можно грузить объемом больше 4 ГБ Да даже пусть чуть меньше 4 ГБ, чтобы одним куском записать. Кроме всего прочего, это будет время немало занимать. Да и обрабатывать на серваке тоже время нужно. Не говоря о том, что загрузить это всё в БД тоже нехило так получится сервер нагрузить.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

Ну да, я так и предполагал. Одна запись, один текст. Это было хорошая идея до тех пор пока бы не понадобилась разбивать текст на фрагменты, потому что LONGTEXT хорошо до тех пор пока не пришлось сделать выдачу на страницу так, чтобы юзер не уснул, чтобы не оборвало по тайм-ауту и т.п. И тут скорее всего на помощь придет MEDIUMTEXT максимальным размеров 16Мб, а лучшим вариантом будет TEXT! со своими скромными 16K. Однако при существовании желания запостить "войну и мир" надо будет сделать так, чтобы названия книг хранились в одной таблице, а сами книги, подробленные на куски размером с TEXT хранились в связанной с таблицей названий таблице книги. И еще мне не понятно при чем тут юзер и где его роль в хранении книг?

В ситуации сейчас которая получилась из разговора моя структура таблиц выглядит так:
Автор : id | name | soname -> Книги: id | author-id | bookname | -> Текст : id | book-id | text.

Надо дальше разговаривать потому что БД строиться бесплатно :-)